DRAFT UGANDA STANDARD  
  DUS 1580-1:2014 
First Edition  
2017 -mm-dd 
 
 
 Referenc e number  
DUS 1551: 2017 
© UNBS 2017   
  
Gaming equipment  - Part 1: Requirements for casinos  
 
 
 
 
 
 
 
 
   
 
 
 DUS 1580-1 : 2014 
ii © UNBS 2017  – All rights reserved  
 Compliance with this standard does not; of itself confer immunity from legal obligations  
A Uganda Standard does not purport to include all necessary provisions of a contract. Users are 
responsible for its correct application  
© UNBS 2017  
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilised in any 
form or by any means, electronic or mechanical, including photocopying and microfilm, without prior written 
permission from UNBS. 
Requests for permission to reproduce this document should be addressed to 
The Executive Director 
Uganda National Bureau of Standards 
P.O. Box 6329 
Kampala 
Uganda 
Tel: 256 414 505 995 
Fax: 256 414 286 123 
E-mail: unbs@infocom.co.ug  
Web: www.unbs.go.ug  DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  iii 
 Contents Page 
1 Scope  ................................ ................................................................ ................................ ..................... 7 
5. General requirements  ................................................................ ................................ ......................... 15 
5.1 Documentation  ................................ ................................ ................................................................ .... 15 
5.2 Enclosure construction ............................................................................................................................. 16 
5.3 Enclosure identification ............................................................................................................................ 16 
5.4 Enclosure security ..................................................................................................................................... 17 
5.5 Access detection systems ........................................................................................................................ 17 
5.6 Logic areas ................................................................................................................................................. 18 
6 Electrical requirements ................................................................................................................................ 19 
6.1 Enclosure wiring ........................................................................................................................................ 19 
6.2.2 Electromagnetic immunity ..................................................................................................................... 19 
6.2.3 Magnetic immunity ................................................................................................................................. 19 
6.2.3.1 Immunity to alternating magnetic field at mains frequen cy ............................................................ 19 
6.2.3.2 Immunity to impulse magnetic field ................................................................................................... 19 
6.2.4 Temporary electrostatic disruption ...................................................................................................... 19 
6.2.5 Fast transient voltage ............................................................................................................................. 20 
6.2.6 Surge voltage .......................................................................................................................................... 20 
6.2.7 Long-term voltage level change test .................................................................................................... 20 
6.2.8 Surges and sags of voltage ................................................................................................................... 20 
6.3 Power supply .............................................................................................................................................. 21 
7 Computer and peripheral hardware requirements .................................................................................... 21 
7.1 Random access memory ........................................................................................................................... 21 
7.2 Critical memory requirements .................................................................................................................. 21 
7.3 Program memory storage requirements ................................................................................................. 22 
7.4 Programmable logic elements .................................................................................................................. 22 
7.5 Circuit boards ............................................................................................................................................. 22 
7.6 Switches and jumpers ............................................................................................................................... 22 
7.7 Communication .......................................................................................................................................... 22 
7.9 Printers (if applicable) ............................................................................................................................... 23 
8 Transaction system requirements .............................................................................................................. 23 
8.1 Coin acceptance systems ......................................................................................................................... 23 
8.2 Coin dispensing devices ........................................................................................................................... 24 
8.3 Bill acceptor requirements ........................................................................................................................ 25 
8.4 Bill validator requirements ........................................................................................................................ 26 
8.5 Electronic funds transfer .......................................................................................................................... 29 
8.6 Credit redemption ...................................................................................................................................... 29 
8.7 Cashout by printed ticket .......................................................................................................................... 30 
9.1 Source code ................................................................................................................................................ 30 
9.1.1 General ..................................................................................................................................................... 30 
9.1.2 Control and upgrade ............................................................................................................................... 31 
9.1.3 Verification ............................................................................................................................................... 31 
9.2 Critical memory requirements .................................................................................................................. 32 
9.2.1 Critical memory ....................................................................................................................................... 32 
9.2.2 Maintenance ............................................................................................................................................ 32 
9.2.3 Detection of corruption .......................................................................................................................... 32 
9.2.4 Recovery .................................................................................................................................................. 32 
9.3 Program memory storage ......................................................................................................................... 33 
9.3.1 Labelling .................................................................................................................................................. 33 
9.3.2 WORM memory ....................................................................................................................................... 33 
9.3.3 Reprogrammable memory ..................................................................................................................... 33 
9.3.4 Read/write storage .................................................................................................................................. 34 
9.3.5 ROM program storage ............................................................................................................................ 34 
9.3.6 Verification ............................................................................................................................................... 34 DUS 1580-1 : 2014 
iv © UNBS 2017  – All rights reserved  
 9.4 Random number selection process ......................................................................................................... 35 
9.4.1 General ..................................................................................................................................................... 35 
9.4.2 RNG requirements .................................................................................................................................. 36 
9.4.3 Background RNG activity ...................................................................................................................... 36 
9.5 Information display .................................................................................................................................... 37 
9.5.1 Display methodology .............................................................................................................................  37 
9.5.2 Recovery .................................................................................................................................................. 37 
9.5.3 Last game information ...........................................................................................................................  37 
9.6 Prescribed display formats ....................................................................................................................... 38 
9.7 Communication .......................................................................................................................................... 38 
9.8 Metering – Reports and displays ............................................................................................................. 39 
9.9 Metering – Player displays ........................................................................................................................ 41 
9.10 Labelling ................................................................................................................................................... 43 
9.11 Simulator .................................................................................................................................................. 43 
10 Operational requirements ..........................................................................................................................  44 
10.1 Access to restricted features ................................................................................................................. 44 
10.2 Set- up – Device configuration ................................................................................................................ 44 
10.2.1 Configuration of variables ................................................................................................................... 44 
10.2.2 Reconfiguration .................................................................................................................................... 44 
10.3 System security ....................................................................................................................................... 44 
10.4 Master reset .............................................................................................................................................. 45 
10.5 Door open procedures ............................................................................................................................  46 
10.6 Door close procedures ............................................................................................................................  46 
10.7 Audit mode ............................................................................................................................................... 46 
10.8 Demonstration mode ...............................................................................................................................  47 
10.9 Idle mode .................................................................................................................................................. 48 
10.10 Test/service mode ................................................................................................................................ . 48 
10.11 Power save mode .................................................................................................................................. 49 
10.12 Mechanical reels and wheels ................................................................................................................ 50 
10.13 Video displays ........................................................................................................................................ 50 
10.14 Electronic funds transfer system ......................................................................................................... 51 
10.15 Player input ............................................................................................................................................ 52 
10.16 Jackpot controllers and displays ......................................................................................................... 52 
10.16.1 General requirements ......................................................................................................................... 52 
10.16.2 Handling of faults ...............................................................................................................................  52 
10.16.3 Display requirements ......................................................................................................................... 53 
10.16.4 Jackpot awards ................................................................................................................................... 53 
10.16.5 Controller requirements ..................................................................................................................... 53 
10.16.6 Security of jackpot parameters ......................................................................................................... 54 
 
 DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  v 
 Foreword 
Uganda National Bureau of Standards (UNBS) is a parastatal under the Ministry of Trade, Industry and 
Cooperatives established under Cap 327, of the Laws of Uganda.  UNBS is mandated to co-ordinate the 
elaboration of standards and is  
(a) a member of International Organisation for Standardisation (ISO) and  
(b) a contact point for the WHO/FAO Codex Alimentarius Commission on Food Standards, and  
(c) the National Enquiry Point on TBT/SPS Agreements of the World Trade Organisation (WTO). 
The work of preparing Uganda Standards is carried out through Technical Committees. A Technical Committee 
is established to deliberate on standards in a given field or area and consists of representatives of consumers, 
traders, academicians, manufacturers, government and other stakeholders. 
Draft Uganda Standards adopted by the Technical Committee are widely circulated to stakeholders and the 
general public for comments. The committee reviews the comments before recommending the draft standards 
for approval and declaration as Uganda Standards by the National Standards Council.  
Committee membership 
The following organisations were represented on the Management Systems’  Standards Technical Committee, 
UNBS/TC 10/SC11, during the development of this standard:  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 DUS 1580-1 : 2014 
vi © UNBS 2017  – All rights reserved  
 Introduction 
The requirements in this standard are supplementary to and do not replace any of the requirements of 
relevant Acts (see foreword) or supporting National Lotteries Board Regulations of the national  
licensing in Uganda. 
The intention of this document is to place sufficient controls on software, gaming equipment and 
operations to ensure that wagering is fair, safe, secure, reliable, and auditable. 
It is not the intention of this document to unreasonably 
a) mandate a single solution or method of realizing an objective, 
b) limit technology application of software and gaming equipment, 
c) limit creativity and variety of choice, 
d) limit marketability, or 
e) advantage any supplier or manufacturer of software and gaming equipment. 
 
Alternative implementations to the requirements contained in this document will be considered on a 
case- by-case basis by the licensing authority  
Situations or considerations that arise from evaluation of systems, which have not been addressed in 
this document (e.g. owing to omissions or the use of new technology), will be resolved at the sole 
discretion of the licensing as part of the approval process. 
 
  
 DUS 1580-1 : 2014  
vii  
 Gaming Equipment – Part 1: Requirements for Casinos
1 Scope 
1.1 This Draft Uganda Standard provides the constructional and operational requirements for 
Gaming Devices that reside on, or are operated on (or both), the gaming floor of a casino. 
1.2 Equipment covered by the requirements of this part of DUS 1580-1:2014 includes: 
a) gaming machines, 
b) Jackpot controllers and displays and,  
c) Machine consoles. 
NOTE 1 Legislation (see foreword) requires that this equipment be attached to an electronic 
monitoring and control system, and therefore the requirements of DUS 1580-3:2014 are also 
applicable. 
NOTE 2 There is compulsory legislation in Uganda relating to the safety of electrical appliances 
and electronic equipment, and to limits on the emission of electromagnetic radiation. These 
requirements are not covered in this part of DUS 1580-1:2014 and compliance with the 
requirements of this part of DUS 1580-1:2014 does not ensure compliance with the 
aforementioned compulsory legislation covered by the Lotteries and Gaming Act 2016. 
 
2 Application  
 
This standard applies among others to all types of gaming devices operated within the casino 
which include: gaming machines, jack pot controllers and displays and machines consoles as 
specified in the scope of the National Lotteries and Gaming Act 2016 . 
 
3 Normative references 
 
The following referenced documents are indispensable for the application of this document. For 
dated references, only the edition cited applies. For undated references, the latest edition of the 
referenced document (including any amendments) applies. 
SANS 222/CISPR 22, Information technology equipment – Radio disturbance characteristics – 
Limits and methods of measurement . 
US 61000-4-2/IEC 61000-4-2, Electromagnetic compatibility (EMC) – Part 4-2: Testing and 
measurement techniques – Electrostatic discharge immunity test .  
US 61000-4-3/IEC 61000-4-3, Electromagnetic compatibility (EMC) – Part 4-3: Testing and 
measurement techniques – Radiated, radio-frequency, electromagnetic field immunity test . 
US 61000-4-4/IEC 61000-4-4, Electromagnetic compatibility (EMC) – Part 4-4: Testing and 
measurement techniques – Electrical fast transient/burst immunity test . 
US 61000-4-5/IEC 61000-4-5, Electromagnetic compatibility (EMC) – Part 4-5: Testing and 
measurement techniques – Surge immunity test . 
US 61000-4-8/IEC 61000-4-8, Electromagnetic compatibility (EMC) – Part 4-8: Testing and 
measurement techniques – Power frequency magnetic field immunity test . DUS 1580-1 : 2014 
viii © UNBS 2017  – All rights reserved  
 US 61000-4-9/IEC 61000-4-9, Electromagnetic compatibility (EMC) – Part 4-9: Testing and 
measurement techniques – Pulse magnetic field immunity test . 
Lotteries and Gaming Act; 2016 . 
 
US 532, US 534 
Occupational Safety and Health Act; 2006 
 
4 Terms and definitions 
 
For the purposes of this standard, the following terms and definitions shall apply.  
4.1.1 
Approved 
approved by the Lotteries and Gaming Regulatory Board   
4.1.2 
Attract mode  
information or graphics that relate to the game or games available on that machine that the 
Gaming Machine ( GM) may display during the GM's idle mode 
4.1.3 
Auto play 
facility in a GM that automatically plays the next game following the completion of the current 
game 
4.1.4 
bet 
wager amount of coins or credits put at risk at the commencement of a game or during a game 
4.1.6 
Bill acceptor 
banknote acceptor bill handling system including the bill validator and all other handling 
components, including the bill storage canister  
4.1.7 
Bill validator 
note acceptor device that is fitted with photo-optic and other sensors (internal or external to the 
device) and that is used to accept and validate paper or plastic legal tender or coupons approved 
in that jurisdiction 
4.1.8  
capping 
truncating situation where the amount added to the win meter from a single play within a game is 
less than either 
a) the monetary or credit value for the winning combination, or DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  ix 
 b) the sum of the monetary values or sum of the credit values for the winning combinations, from 
a single play within a game that is displayed to the player on the paytable 
4.1.9  
Cash 
coins, banknotes, tokens, magnetic or integrated circuit (e.g. “smart”) cards or any other legal 
representation of money in the gaming environment 
4.1.10  
Cashout 
action initiated by a player when redeeming available credits from a GM 
NOTE This term is used whether the GM pays credits from the hopper, by electronic transaction 
or by a ticket. 
4.1.11  
Certification authority 
Authority appointed to certify all Gaming Devices (GDs), both hardware and software 
4.1.12 coin acceptance device 
Coin input devices, together with the coin validator or comparator, photo-optic sensors (internal or 
external to the comparator), and any additional devices used to accept and validate a coin 
4.1.13 coin acceptance system 
System that comprises the coin acceptance device and the associated software required to 
validate the physical input of coins and the conversion of these coins into credits 
4.1.14 Coin dispensing device 
Device, together with coin storage mechanism (e.g. hopper or tubes), photo-optic and other 
sensors (internal or external to the device), and any other devices and pathways used to pay out 
coins to the player 
4.1.15 Critical data 
Data contained in critical memory as follows: 
a) all metering required by this part of 1580 -1:2014 
b) GD or game configuration data (or both); 
c) Information that pertains to the last five games (including the current game, if incomplete); 
d) Software state (the last normal state the GD software was in before interruption); 
e) Current credits; and 
f) Information regarding any significant events. 
NOTE Information pertaining to the last five games is only required if applicable to that type of 
GD. 
4.1.16 critical memory 
Memory locations for storing critical data DUS 1580-1 : 2014 
x © UNBS 2017  – All rights reserved  
 4.1.17 Electronic Funds Transfer 
Advanced funds transfer system whereby credits are transferred to or from a GM by any means 
other than coins, tokens or banknotes 
4.1.18  
Error event 
Set of operational conditions for a GD that constitutes a deviation from the normal conditions or 
the conditions specified during a game, during idle mode or during data interchange with another 
GD 
4.1.19 Feature 
Activity within a game triggered by an outcome within that game 
NOTE Any additional free game, free spin of certain reels, or secondary choice necessary to 
complete a game is considered a feature. 
4.1.20 fixed jackpot 
Fixed award (additional to the game's paytable) available to be won by a player as a result of an 
event on the GD 
4.1.21 gamble feature 
Feature within a game that is only entered following a win, and which involves the risking of all or 
part of the result of that win 
NOTE Gamble feature bets may incorporate a variety of symbols, player choices, or win chances. 
4.1.22 game 
combination of events, including player interaction with the GD, that determine what prize may 
eventually be won from an amount staked or bet by the player 
NOTE 1 Definitions of "game" in legislation (see foreword) take precedence over this definition. 
NOTE 2 The game commences when the player 
a) makes a bet from the player's credit meter that is not part of any previous game, or 
b) inserts one or more coins or any form of wager and game play is initiated. 
NOTE 3 The game is considered completed when the player 
a) cannot continue play activity without committing additional credits from the credit meter and 
b) has no credits at risk. 
NOTE 4 The following elements are all considered to form part of a single game, in other words, 
the game is 
not considered to have been completed until all the "elements" have been completed: 
a) games that trigger a free game feature and any subsequent free games; 
b) features that occur or that are triggered in a single game; 
c) "second screen" bonus feature(s); 
d) games with player choice (for example, draw poker or blackjack); DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xi 
 e) games where the rules permit wagering of additional credits (for example blackjack insurance 
or the second 
part of a two-part keno game); and 
f) gamble feature (for example, double-up). 
NOTE 5 The game is not considered to be completed until all the appropriate meters for the game 
have been updated. 
4.1.23  
gaming device 
any device manufactured with the intention of being used for gaming purposes, including the 
monitoring and control system, GMs, host, data controller unit, bank controller or any combination 
of 
these, including software 
4.1.24  
gaming machine 
gambling machine 
slot machine 
machine with which the player interacts for the purpose of gaming 
NOTE The definitions in the appropriate legislation (see foreword) take precedence over this 
definition. 
 
4.1.26 host 
central computer(s) of a monitoring and control system on which the software is loaded, and that 
is 
(are) certified by the Certification Agent 
4.1.27  
idle mode 
state in which a GD is powered up, but is not active in the execution of a game, a test routine, an 
audit, a calibration, or a data interchange with an external device 
4.1.28 jackpot 
award, in excess of the maximum prize as specified on a game's paytable, that is available to be 
won by a player as a result of activity on a GM 
4.1.29 legislation 
National Lotteries and Gaming Act 2016; that deals with gambling, gaming, wagering, betting or 
horse-racing and any regulation or rule made in terms of such Act 
4.1.30 logic area DUS 1580-1 : 2014 
xii © UNBS 2017  – All rights reserved  
 secure enclosure area that houses electronic components that have the potential to influence the 
operation of the host, the data controller unit, the bank controller or the Gaming Machines 
4.1.31 master reset 
intentional memory clear of the Random Access Memory and other volatile memory of a GD 
4.1.32 maximum prize 
maximum win that is permissible in terms of legislation (see foreword) applicable in that 
jurisdiction 
4.1.33 maximum stake 
maximum bet or wager that is permissible in terms of legislation (see foreword) applicable in that 
jurisdiction 
4.1.34  
metamorphic feature 
metamorphic game feature of a game or series of games that is not completely independent of 
play history 
4.1.35 memory 
locations within the GD for storing electronic data, and the data stored therein 
3.1.36  
monitoring and control system 
central electronic monitoring system 
central monitoring system host, data controller unit, bank controller and communications interface 
to each gaming machine 
and the connections between them 
4.1.37 multigame 
more than one game type offered by the gaming software on a single GM  
4.1.38  
multiple machine jackpot 
fixed or progressive award (additional to the game's paytable) available to be won by any player 
playing one of the GDs that participates in a fixed or progressive jackpot, as a result of an event 
on 
the GD being played 
4.1.39  
paytable 
list of winning combinations with their associated win amounts, rules of the game and 
explanations as to how a winning combination may be made up that is, or is capable of being, 
displayed to the player 
4.1.40  DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xiii 
 period meter 
soft meter implemented in software that is used in a similar way to the odometer (for example "trip 
meter") on a car 
NOTE This meter is used to record meter values since a given event (for example, coins and bills 
in since the last clearance). 
4.1.41  
progressive jackpot 
additional variable award (additional to the game's paytable) available to be won by a player as a 
result of an event on a GD 
NOTE The progressive jackpot starts at the base value and is incremented by a nominated 
amount based on activity on the GD(s) connected to the progressive jackpot gaming equipment. 
4.1.42  
Lotteries and Gaming Regulatory Board (LGRB) 
body responsible in terms of the relevant legislation (see foreword) for issuing and controlling GD 
approvals 
4.1.43  
random win 
mystery win win that is given by the GD for a result not necessarily displayed to the player on the 
prize table of the GD 
4.1.44 reprogrammable memory device 
type of on-chip memory storage device 
4.1.45 
return to player  
ratio of total winnings to the total turnover, expressed as a percentage  
4.1.46 
secure area 
area within a GD that may only be accessed by means of a key and on approval  
4.1.47 security event 
event which indicates that a GD has been tampered with or that attempted fraud has taken place 
4.1.48 significant event 
set of operational conditions to be recorded by the monitoring and control system for GDs during 
a game, during idle mode or during data interchange with another GD 
4.1.49 software shell 
base software or the operating system software in which there is no game information 
4.1.50 stake 
total monetary value of all bets or wagers put at risk to play a single game DUS 1580-1 : 2014 
xiv © UNBS 2017  – All rights reserved  
 4.1.51 
stand-alone jackpot fixed or progressive award (additional to the game's paytable) available to 
be won by a player on a single GD as a result of an event on that GD 
4.1.52  
static artwork 
artwork that is physically printed on glass, plastics, non-removable stickers, etc. and displayed on 
the GM to the player 
4.1.53 test laboratory 
laboratory whose test results are accepted by the CA 
4.1.54  
token 
circular element with an indicated monetary value, excluding legal tender such as coins, that 
might be put into GDs 
4.1.55 tokenization 
situation where the insertion of one coin either gives rise to more than one credit being made 
available to the player, or where more than one coin is required to be inserted in the Coin 
Acceptance Device for the player to receive one credit 
4.1.56  
turnover 
handle 
monetary value of the total of all cash or credits (or both) staked on game play 
4.1.57 win 
award 
prize 
number of credits or monetary value awarded to the player as a result of a winning combination or 
combinations at the end of a single play within a game 
4.1.58  
Winning combination 
one or more winning patterns that result in credits being added to 
a) the total win meter, and 
b) the win display 
4.1.59 winning pattern 
set of symbols that participates in a winning combination (including substitution) 
4.1.60  
winnings DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xv 
 monetary value of the total of all coins or credits added to the total win meter and the win display 
during a game, as a result of any game outcome according to the game rules, resulting in credits 
being added to the total win meter and to the win display 
NOTE A GM might display this value in credits or in monetary value. 
4.2 Abbreviations 
AFT: advanced funds transfer 
BCD: binary coded decimal 
CA: Certification Authority 
CAD: coin acceptance device 
CAS: coin acceptance system 
CDD: coin dispensing device 
CPU: central processing unit 
EFT: electronic funds transfer 
EMC: electromagnetic compatibility 
EMI: electromagnetic interference 
EPRO M: erasable programmable read-only memory 
GD: gaming device 
GM: gaming machine 
I/O: input/output 
LAN: local area network 
LGRB: Lotteries and Gaming Regulatory Board 
MCS: monitoring and control system 
PCB: printed circuit board 
PIN: personal identification number 
PLA: Provincial Licensing Authority 
PLD: programmable logic device 
RAM: random access memory 
RNG: random number generator 
ROM: read-only memory 
RTP: return to play er 
WORM: write-once read-many 
5. General requirements 
5.1 Documentation 
5.1.1 Each GD model shall have readily available pertinent operating and service manuals. DUS 1580-1 : 2014 
xvi © UNBS 2017  – All rights reserved  
 5.1.2 The operating manual shall accurately depict the use of the GD in its operating environment, 
and shall provide sufficient detail and be sufficiently clear in its wording and diagrams to enable 
the relevant personnel to understand the manual with minimal guidance. 
5.1.3 The service manual shall accurately depict the GD that it is intended to cover, and shall 
provide sufficient detail and be sufficiently clear in its wording and diagrams to enable a 
competent person to perform repair and maintenance in a way that is conducive to the long-term 
reliability of the GD. 
5.1.4 Software documentation shall include an edit history that provides details of all changes to 
code (what, why, who and when). 
5.1.5 Operational manuals shall have an English version for easier communication. 
5.2 Enclosure construction 
5.2.1 The enclosure shall be of a sturdy construction with a locking system that resists the kind of 
unauthorized entry that the GD is likely to be subjected to in a gaming venue. The enclosure shall 
be so designed to protect internal components from any external abuse to which the GD is likely 
to be subjected in a gaming venue. 
5.2.2 Areas of the enclosure that are accessible to patrons and staff shall be so constructed and 
so finished as not to create a safety hazard or create a risk of injury.  
5.2.3 All protuberances (for example, buttons and handles) on the enclosure that are accessible 
to patrons or staff, and all attachments to the enclosure (for example, labels and identification 
plates) shall be sufficiently robust to prevent their unauthorized removal. 
5.2.4 Door support devices shall be of construction solid enough to prevent sagging of the door 
and any problems with door sensor alignment. 
5.2.5 Spilled liquid shall not be able to enter the logic area, the power supplies, or areas that 
contain wiring of voltage exceeding 32V. 
5.2.6 Hinge centre pins, if used, shall not be able to be removed without leaving evidence of 
tampering. 
5.3 Enclosure identification 
5.3.1 The GD shall have an identification badge that bears the following information 
 permanently affixed to the exterior of the enclosure by the manufacturer in a position that allows it 
to be read easily after the equipment has been installed: 
a) the name of the manufacturer; 
b) a unique serial number; and 
c) the date of manufacture. 
5.3.2 The serial number shall be marked or affixed in a permanent manner onto the interior of the 
GD enclosure in a position that allows it to be read easily after the equipment has been installed. DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xvii 
 5.3.3 Each external key switch of the gaming equipment enclosure, switches and player buttons 
shall be labelled, either according to its function or to the series of events initiated by its activation. 
If a key lock initiates some kind of user activity other than simply unlocking a door, then its 
function shall be labelled (for example, if a key lock turns one way to enter audit mode, and turns 
the opposite way to enter cancel credit mode, then both directions shall be labelled accordingly). 
5.4 Enclosure security 
5.4.1 All of a GD's components that do not form part of the player's input interface (for example, 
buttons) shall be stored within one or more secure areas of the GD. Unauthorized access to a 
secure area by physical means shall be detectable. This requirement does not apply to areas that 
only provide access to lighting components, such as top boxes or belly panels. 
5.4.2 Where holes, gaps or slots exist in the exterior of a secure area, there shall be sufficient 
protection to ensure that the insertion of foreign objects shall not compromise the security or 
safety of that secure area. 
5.4.3 A secure area shall resist forced entry and shall retain evidence of attempts at such entry. 
5.4.4 Access to a locked area "A" shall not be possible from another locked area "B" without the 
use of a key or other secure access device for locked area "A". 
5.5 Access detection systems 
5.5.1 All access points shall have access detection sensors. 
5.5.2 The door access detection system shall provide a signal to enable the monitoring and 
control system to interpret whether access to a logic area has occurred, regardless of whether 
mains power is switched on or off, or whether the GD is on-line or off-line. It shall remain able to 
detect this event with the mains power off for at least 24 h. This event shall be reported once the 
mains power is restored, or when the GD is connected back on line, whichever occurs first. 
5.5.3 When the door of the GD is shut, it shall not be possible to insert any object into the GD in 
such a way that the access detection sensor is disabled. 
5.5.4 The access detection system shall be secure against attempts to disable it or to interfere 
with its normal mode of operation. Cable runs and mountings for the logic area access sensors 
shall be securely protected. 
5.5.5 It shall not be possible to create a false alarm door open condition (for example by bumping 
the door ). 
5.5.6 If the access detection system is disconnected, the gaming equipment shall interpret this 
action as the door having been opened. 
5.5.7 The GM shall deactivate game play upon the opening of a door but may immediately 
reactivate when the door is closed, unless it has noticed the changing of counters or insertion of 
coins while this door is open, which is deemed to be interference and precludes automatic 
reactivation unless the GM was placed in test mode. In such case a significant event message DUS 1580-1 : 2014 
xviii © UNBS 2017  – All rights reserved  
 shall be sent and the monitoring and control system shall add the staff card number to the event 
message. If no card number is available, the message shall be tagged by the monitoring and 
control system as an unauthorized access. 
5.6 Logic areas 
5.6.1 Items of electronic component that shall be housed in one or more logic areas shall be: 
a) CPUs and other electronic components involved in the operation and calculation of game play 
(for example, game controller electronics, and components housing the game or system firmware 
program storage media); 
b) electronics involved in the operation and in the calculation of game results; 
c) electronics involved in the calculation of game display, and components housing display 
program storage media (passive display equipment exempted); 
d) communication controller electronics, and components housing the communication program 
storage media; and 
e) all reprogrammable memory devices that affect the game play function of the GD. 
5.6.2 Communication, I/O and display interfaces that do not significantly influence the GD's 
behaviour shall be excluded from the logic area. 
5.6.3 If the logic door is opened more than once while the GD is off-line or powered off, the GD 
shall, for the purposes of event reporting, treat this as a single entry. 
5.6.4 There shall be a facility for storing a logic door open event for at least 14 d. 
5.6.5 Provision shall be made on the logic door so that a physical seal can be fitted which would 
be broken if the logic area was accessed.  
5.6.6 It shall not be possible (without a detailed technical knowledge of the machine) to reset the 
logic area door open state (without detection) when the logic door is open (for example, the 
access detection system shall not be able to be tampered with or be replaced without leaving 
evidence that this has occurred). 
5.6.7 It shall not be possible to insert a device into the logic area that can disable the door open 
sensor of the logic area when the door is shut without such act being detected or leaving evidence 
of tamperin g. 
5.6.8 If the logic area consists of a board with no door as such, as the entire board can be 
removed and accessed, the security requirements for the logic doors shall extend to logic units 
(i.e. removal of the board is equivalent to opening the door). 
5.6.9 It shall not be possible to reset the logic area door open state, by either hardware or 
software mean s, if the logic door is still open. 
5.6.10 If the logic area is not located inside another secure area of the GD it shall possess a 
second means of physically securing the area by a lock in addition to the provision for fitting a 
seal. DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xix 
 5.6.11 It shall not be possible to access the data bus, address bus, or control lines of any of the 
above-mentioned circuit boards without gaining access to a logic area. 
6 Electrical requirements 
6.1 Enclosure wiring 
6.1.1 All connectors and wires shall be easily identifiable, both in the GD itself and on the circuit 
diagrams in the manuals. 
6.2 Electromagnetic compatibility 
6.2.1 Electromagnetic interference 
The GD shall comply with the requirements for class A ITE equipment. 
NOTE Deleted by amendment No. 2 
6.2.2 Electromagnetic immunity 
When the GD is tested in accordance with the procedure given in SANS 61000-4-3, at an electric 
field strength of 3 V/m over the frequency range 80 MHz to 1,0 GHz with 80 % AM modulation at 
1 kHz, the GD shall not divert from normal operation by the application of EMI. 
6.2.3 Magnetic immunity 
6.2.3.1 Immunity to alternating magnetic field at mains frequency 
A GD shall not have its security properties changed by the application of a magnetic interference 
level to the GD. When tested in accordance with US IEC 61000-4-8, the GD shall withstand a 
magnetic field that alternates at 50 or 60 and that has an amplitude of 1 A/m. The GD shall exhibit 
a capacity to recover or reset and complete any interrupted play without loss or corruption of any 
control or data information associated with the GD. 
6.2.3.2 Immunity to impulse magnetic field 
A GD shall not have its security properties changed by the application of a magnetic interference 
level to the GD. When tested in accordance with US IEC 61000-4-9, the GD shall withstand an 
impulse magnetic field strength of 100 A/m (peak) and shall exhibit a capacity to recover or reset 
and complete any interrupted play without loss or corruption of any control or data information 
associated with the GD. 
6.2.4 Temporary electrostatic disruption 
When the GD is tested in accordance with US IEC 61000-4-2, at a level of 8 kV for air discharge 
and at 4 kV for contact discharge, 
a) it shall exhibit a capacity to recover or reset and complete any interrupted play without loss or 
corruption of any control or data information associated with the GD; and 
b) there shall be no abnormal payout from a CDD. DUS 1580-1 : 2014 
xx © UNBS 2017  – All rights reserved  
 6.2.5 Fast transient voltage 
The GD shall employ sufficient power supply filtering to prevent disruption to the device when the 
GD is tested with the application of the following fast transient voltages (rise time: 5 ns, duration: 
50 ns) in accordance with US/IEC 61000-4- 4: 
a) to the a.c. power lines of the power supply: 0,5 kV; and 
b) to the I/O lines: 0,5 kV. 
The GD shall exhibit a capacity to recover or reset and complete any interrupted play without loss 
or corruption of any control or data information associated with the GD. 
6.2.6 Surge voltage 
The GD shall employ sufficient power supply filtering to prevent disruption when tested in 
accordance with SANS 61000-4- 5. When a surge voltage (rise time: 1,2 μs, duration: 50 μs) of 1 
kV is applied to the a.c. power lines of the power supply and 2 kV is applied to earth, the GD shall 
exhibit a capacity to recover or reset and complete any interrupted play without loss or corruption 
of any control or data information associated with the GD. 
6.2.7 Long-term voltage level change test 
When a GD is operating at its rated voltage, and the voltage is changed to – 253 V for 15 min, 
and – 207 V for 15 min before being returned to the rated voltage, the GD shall show the capacity 
to recover or reset and to complete any interrupted play without loss or corruption of any control 
or data information associated with the GD. There may be a break between the two periods of 
abnormal operation. 
NOTE:  This requirement is to demonstrate the ability of the GD to operate normally during voltage 
changes within the tolerances with which utility companies are required to comply (typically 10 % 
above and 10 % below the nominal 230 V). 
6.2.8 Surges and sags of voltage 
When the voltage supply to the GD is varied in accordance with the following procedures, the GD 
shall exhibit a capacity to recover, or to reset, and to complete any interrupted play or data 
collection without loss or corruption of any control or data information associated with the GD, or 
any damage to the equipment: 
a) Connect the GD to a variable voltage power supply. Set the supply voltage to the rated value. 
Operate the gaming equipment for 15 min. 
b) Increase the supply voltage rapidly (i.e. within 0,5 s) to 1,20 times the rated voltage, maintain 
for 5 s and return rapidly to the rated voltage. 
c) Reduce the supply voltage rapidly to 0,80 times the rated value, maintain for 5 s and return 
rapidly to the rated voltage. DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xxi 
 NOTE This requirement is to demonstrate that the GD has sufficient power supply filtering to 
prevent disruption to the device in the event of surges or sags in the mains supply of 20 % above 
and 20 % below the nominal supply voltage. 
6.3 Power supply 
6.3.1 All ratings of fuses shall be clearly stated on or near the fuse holder, and switches on the 
power supply shall clearly indicate in a permanent manner the on and off positions. 
6.3.2 The GD shall be able to operate from a 230 V, 50 Hz main power source, which might 
deviate 10 % above and below nominal voltage and 1 % above and below nominal frequency. 
6.3.3 Where a GD enclosure contains more than one power switch, each switch shall be so 
marked in a permanent manner to indicate clearly to which board or component it applies. 
7 Computer and peripheral hardware requirements 
7.1 Random access memory 
7.1.1 GD RAM data storage shall be capable of reliably preserving its memory contents for at 
least 72 h with the mains power switched off. 
When the battery is at or below its 72 h capacity limit, the GD shall automatically generate a type 
4 significant event message to the monitoring and control system and disable itself. It shall not be 
possible to reset the GD until the battery capacity has increased above the 72 h capacity limit, 
either by recharging or replacement of the battery. If a rechargeable battery is used, the power 
source shall be capable of recharging the battery to its full capacity within 24 h. 
NOTE General significant event messages such as "Tilt" are not acceptable. 
7.1.2 RAM clears of the GD shall not be possible except by accessing the logic area. 
7.1.3 In a GD, batteries shall be secured and connected to the board(s) that contain RAM such 
that the batteries cannot be easily disconnected. 
7.2 Critical memory requirements 
7.2.1 Manufacturers shall ensure that critical data are recorded in at least two physically separate 
and distinct hardware devices (which may be of the same type), either within the GD or the local 
data logger (or both). This critical data record shall be retained on these devices until such time 
that at least the following data have been successfully transmitted to the monitoring and control 
system: 
a) all auditing meters; 
b) current credits; 
c) GD or game configuration data (for example, GM address, denomination); and 
d) significant event information. 
7.2.2 These devices shall be capable of being reliably updated at every critical memory change. DUS 1580-1 : 2014 
xxii © UNBS 2017  – All rights reserved  
 7.3 Program memory storage requirements 
7.3.1 All ROMs (for example, EPROMs, CD-ROMs and PLDs) shall be clearly marked to identify 
the software and the revision level of the information stored in the devices.  
7.3.2 All EPROMs (and PLDs that have erasure windows) shall be fitted with covers over their 
erasure windows. 
7.3.3 EPROMs that contain any settings or programs that have the potential to cause the GD to 
fail to comply with this part of SANS 1718 or with legislation (see foreword) shall not be contained 
within the GD. This includes EPROMs that have a range of parameters that are used for setting 
up the device. 
7.4 Programmable logic elements 
All programmable logic elements that incorporate read-inhibit fuses shall be programmed to 
prevent unauthorized reading or copying of these elements. 
7.5 Circuit boards 
Patch wires and track cuts may be present, but shall be documented in the service manual in an 
appropriate manner. 
7.6 Switches and jumpers 
7.6.1 If switches or jumpers that have the potential to cause the GD not to comply with this part of 
SANS 1718, or with legislation (see foreword), are present, then setting them in a manner that 
would result in non-compliance shall cause the GD to enter "Tilt" mode, which in turn shall be 
signalled to the monitoring and control system. As long as the switch or jumper is set in this 
manner, it shall not be possible to reset the GD. 
7.6.2 All switches and jumpers that have the potential to affect the communications or operational 
characteristics of the GD shall be documented for evaluation by the TL. 
7.7 Communication 
7.7.1 Where multiple GDs communicate over a single multidrop transmission medium, each GD 
shall operate at an accurate and consistent baud rate, which shall ensure consistently accurate 
and error-free communication (over and above the error checking and correction requirement). 
7.7.2 Ports for communication cabling shall be clearly and permanently labelled according to their 
function. 
7.7.3 Ports for communication cabling (other than external ports used exclusively for auditing) 
shall be located within a secure area to prevent unauthorized access to the ports and to the 
attached cables. 
7.7.4 The connection or interaction of a GD with a monitoring and control system shall not affect 
the function of the GD or affect the game in any way, other than to  DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xxiii 
 a) disable the GD or game under the appropriate, approved circumstances (for example, such as 
when off-line to the next point in the monitoring and control system), and 
b) introduce small delays (unperceivable to the player) in the duration of the game, so as to 
facilitate communication with the monitoring and control system. 
NOTE The general nature of the embedded processor usually found in GDs sometimes requires a 
momentarily "hold off" of the next round of communication from the GD to the monitoring and 
control system owing to the sequencing or timing of communications to the monitoring and control 
system by a multitude of connected GDs. 
7.7.5 Where any data (for example, credits, metering information, activation or de-activation 
commands, information that pertains to a game outcome and error events) are transferred 
between a GD and an external device, such as components of a monitoring and control system, 
an error detection and correction system shall be supported. Data errors shall be detectable to a 
minimum accuracy of 99,995 %. 
7.8 Printers (if applicable) 
7.8.1 If a GD is equipped with a printer, the printer shall be located in a secure area other than the 
logic area. 
7.8.2 The printer paper shall be easily replaced without any need to access the logic area of the 
GD. Instructions for the loading of printer paper shall be given in the operating manual. 
7.8.3 The software shall register and react to any printer fault conditions and shall allow the 
machine to complete the printing of the current ticket (if possible) and then pause printing and 
display appropriate on-screen messages. 
8 Transaction system requirements 
8.1 Coin acceptance systems 
8.1.1 Each coin inserted shall register the actual shillings and cents value or the number of credits 
on the player’s credit meter or bet meter. If registered directly as credits, the conversion rate shall 
be clearly stated or be easily discernible from the GD. 
8.1.2 During periods when the gaming equipment is inoperable for any reason, all coins shall 
either be prevented from being inserted, or be rejected. 
8.1.3 The coin input system shall have means by which it can detect or logically deduce (or both) 
when potential cheating is in progress. 
8.1.4 In games where tokenization is used, each valid coin inserted shall register a number of 
credits that are clearly stated on the machine artwork, video or other form of information display. 
8.1.5 The CAS shall be able to 
a) not have its coin path easily altered from the outside of the GD without leaving evidence of 
physical modification, DUS 1580-1 : 2014 
xxiv © UNBS 2017  – All rights reserved  
 b) deliver an accepted coin to the correct area of the gaming equipment, c) credit the customer's 
credit balance with the appropriate shillings and cents value or number of credits for each 
accepted coin, and to return all other coins to the coin tray, and d) de tect and prevent attempted 
fraud. 
8.1.6 The software shall direct coins to either the CDD or to the coin drop box. The "CDD full" 
detector shall be continually monitored to determine whether a change in diverter status is 
required. 
If the state of the detector changes, the diverter shall operate as soon as possible after the state 
change without causing a disruption of coin flow, or creating a coin jam. 
8.1.7 Diverter operations shall be dependent only on CDD sensor status, not software counters. If 
a software counter is used, it shall be used in conjunction with a mechanical sensor, which shall 
override the software counter. 
8.1.8 Coin validation shall be electronically based and be so designed as to ensure that each coin 
inserted and accepted as valid by the GD is added to the credit meter and that it updates all 
appropriate meters. 
8.2 Coin dispensing devices 
8.2.1 The CDD shall have detection devices to enable the GD to interpret and act upon conditions 
when the CDD is empty or when the CDD malfunctions. 
8.2.2 The CDD shall be resistant to manipulation such as by the insertion of foreign objects into 
the output path. 
8.2.3 If a GD can be operated with the use of coins and is fitted with a CDD, the CDD shall be 
located in a suitably secured area within the GD. 
8.2.4 If the GD does not issue clear instructions on the steps necessary either to perform a CDD 
refill or to reset the fault when a "CDD jam", "CDD empty" error message or equivalent wording is 
displayed, then these instructions shall be clearly set out in the operator manual. 
8.2.5 If power to the CDD is removed, the CDD should not dispense extra coins. If additional 
coins are dispensed, this shall only be acceptable as long as this extra payout is not reflected on 
the GD's meters, and therefore does not affect the collection of taxes. 
8.2.6 A GD shall not permit a cashout to be performed during any of the following conditions: 
a) during game play; 
b) while the GD is in demonstration, test or audit mode; and 
c) while the GD is in a fault condition that requires manual activation. 
NOTE Manual reactivation implies that the GD is reactivated for game play before the cash out is 
permitted. DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xxv 
 8.2.7 If the value of the prize, when added to the player's current credits, exceeds the "maximum 
credit" setting in the GD, the value of the prize shall be dispensed directly from the CDD or a hand 
pay shall be initiated. 
8.2.8 The design and construction materials of a CDD shall be of an acceptable quality and the 
CDD shall require no adjustments for at least the manufacturer's recommended maintenance 
period. 
8.3 Bill acceptor requirements 
8.3.1 The banknote acceptor device shall perform a self-test at each power up. In the event of a 
self-test failure, the banknote acceptor shall automatically disable itself (i.e. enter banknote reject 
state) until the error state has been cleared. 
8.3.2 If burning materials enter a banknote acceptor, the only degradation permitted is for the 
acceptor to reject all banknotes. Entering a state where either incorrect banknotes are accepted, 
or correct banknotes are accepted but not credited to the customer, is not acceptable. 
8.3.3 If liquids are spilled into a banknote acceptor, the only degradation permitted is for the 
acceptor to reject all banknotes. Entering a state where either incorrect banknotes are accepted, 
or correct banknotes are accepted but not credited to the customer, is not acceptable. 
8.3.4 Any interconnecting cable or plug (or both) relative to the banknote acceptor shall have 
some form of strain relief. Knots in the cables when passing through holes in the cabinet or 
housing are not an acceptable means for achieving such strain relief. 
8.3.5 Interconnecting cables from the banknote acceptor device to the GD shall not be exposed 
external to the GD or be readily accessible to unauthorized staff. 
8.3.6 The banknote storage area (for example, receptacle) shall be attached to the GD in such a 
manner that it cannot be easily removed by physical force. It may be located within the GD or 
attached to the base on which the GD is positioned. 
NOTE The relevant jurisdiction may grant dispensation for this requirement if it can be 
demonstrated that an external banknote acceptor has at least the same degree of security as one 
located inside the GD. Areas of security that should be examined when such a dispensation is 
being considered, are: 
a) the physical strength of the attached banknote acceptor device; and 
b) the position and type of fixings (for example, screws, nuts, and bolts). 
8.3.7 The designated path which banknotes traverse and associated handling devices shall be 
designed so that they resist jams and do not impair travel during insertion, acceptance, depositing 
or expulsion of banknotes. 
8.3.8 The designated path which banknotes traverse and associated handling devices shall be of 
solid construction. DUS 1580-1 : 2014 
xxvi © UNBS 2017  – All rights reserved  
 8.3.9 Any access to the banknote acceptor components shall disable the GD from game play until 
such time as the access has been clear ed. 
8.3.10 Any GD that has both a coin and a banknote acceptor is required to include a number of 
security features as follows: 
a) access to the coin drop box shall not give access to the banknote storage area; 
b) access to the banknote storage area shall not give access to the coin drop box; and 
c) the GD shall be able to cater for simultaneous input of banknotes and coins. 
NOTE The rejection of either or both are acceptable options. 
8.3.11 All points in the banknote path shall be easily accessible to allow for inspection and 
clearance by service personnel once valid access is gained to the area in which the banknote 
acceptor is housed. Actions intended to be carried out by persons other than licensed technicians 
shall not require the use of tools. 
8.3.12 The banknote acceptor shall be easily removed for inspection by service personnel. 
8.3.13 Access to ban knote acceptor components and banknote storage areas shall be secured 
by means of a key lock. Access doors for both areas shall be fitted with "door open/close" sensors 
(use of the main door sensor for access to banknote acceptor components is acceptable). 
8.3.14 A GD that contains a banknote acceptor device shall maintain sufficient metering to be 
able: 
to report the following: 
a) the total monetary value of banknotes accepted (banknote money in); 
b) the number or value of banknotes accepted for each banknote denomination; and 
c) the individual shillings value of each of the last five banknotes accepted. 
NOTE These meters are master meters, i.e. to be cleared only on master reset of the GD. 
8.3.15 A GD with a banknote acceptor installed shall comply with the hardware requirements of 
this part of SANS 1718.  
8.3.16 Any access required to clear a banknote jam shall not give access to the banknote storage 
area, except if the jam occurs inside the banknote storage area. 
8.3.17 The keys that open the locks on the banknote storage door shall be different from the 
standard outer door or banknote outer door. They may be the same as the coin drop box door 
keys. 
8.3.1 8 The banknote acceptor device shall have a banknote storage receptacle full sensor. This 
shall be indicated on the GD. The banknote acceptor shall disable itself when the receptacle is full 
but game play may continue. 
8.4 Bill validator requirements 
8.4.1 It shall not be possible to successfully disable any validation feature and thus register any 
counterfeit banknote as a valid banknote. DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xxvii 
 8.4.2 Acceptor devices shall incorporate sophisticated detection methods to validate banknotes by 
suitable evaluation methods. 
8.4.3 If the banknote acceptor only accepts banknotes in a particular direction, orientation, or with 
a particular side facing up, there shall be sufficient instructions on the GD artwork to clearly 
indicate this to the patrons. A label with a symbolic sign of the banknote orientation attached near 
the banknote entry point is considered to be the best method of complying with this requirement. 
8.4.4 The GD may have a facility where the banknote acceptor operation can be disabled or 
enabled by means of an action not available to the player, for example, audit mode or GD cabinet 
access. In the instance of the banknote acceptor being disabled, the GD can still be played using 
coin input. 
8.4.5 A GD shall not register credits as the result of banknote input until the banknote has passed 
the point where it is possible to be rejected by the acceptor or to be withdrawn. 
8.4.6 All invalid banknotes shall be rejected and returned to the player. 
8.4.7 Under no circumstances may credits be lost if banknotes are input during game play. 
8.4.8 All acceptance devices shall be able to detect the entry of valid banknotes and provide a 
method to enable the GD software to interpret and act appropriately upon a valid or invalid input 
(for example, the insertion of counterfeit banknotes). 
8.4.9 The GD shall be able to detect a banknote jam that has occurred. 
8.4.10 A banknote acceptor device shall be implemented with a means to enable or disable 
particular value banknotes. The procedure for setting acceptable banknote values shall be by 
means of a command from the system or access to a secure area of the GD. If permanent artwork 
is used to display the acceptable denominations, the latter method, which requires attending to 
each GD, is preferred. 
8.4.11 The acceptance device(s) shall be electronically based and configured to ensure that it 
only accepts valid banknotes of legal tender or coupons approved for that jurisdiction and rejects 
all others. 
8.4.12 An acceptance device shall include a mechanism which prohibits the input of any 
banknotes, or, alternatively, rejects all banknotes entered during periods when the GD is 
inoperable or deactivated for any reason. 
8.4.13 The GD, if configured for a banknote acceptor device, shall not activate the banknote 
acceptor if any part of the banknote acceptor that relates to the validation process, or to delivery 
of the banknote to the storage area, is missing. 
8.4.14 All accepted banknotes shall be deposited into the secure banknote storage area. 
8.4.15 A banknote acceptor receptacle-full condition need not disable the GD but shall disable 
banknote input. DUS 1580-1 : 2014 
xxviii  © UNBS 2017  – All rights reserved  
 8.4.16 In the case of GDs that support banknote acceptors which implicitly implement tokenization 
of the GD, the following requirements apply to this tokenization aspect: 
a) each valid banknote inserted shall register the actual shillings value or the correct number of 
credits for the current game. If registered directly as credits, the conversion rate shall be clearly 
stated on the GD; and 
b) the GDs shall ensure that all banknotes accep ted shall correctly increment the player’s balance  
(GD or account as the case may be) and relevant meters in all circumstances. This includes, but 
is not limited to, cases of power failure, door open, coin tilt, audit mode entry or any other form of 
deactivation of the GD. 
8.4.17 The GD software shall incorporate a facility which shall automatically disable the banknote 
acceptor once the credit balance of the GD or account, if appropriate, exceeds the limit set in 
legislation (see foreword) expressed in shillings. This limit shall not be able to be exceeded or 
disabled. 
This shilling level may only be set, or changed, by either a down-loadable parameter from the 
system or by accessing the logic area of the GD. This level shall be displayed to the patron in a 
message similar to the following: 
"Notes not accepted if credits over Shs XXX,XX are registered". 
NOTE This information may be displayed as physical artwork. 
8.4.18 If banknote input messages received from the banknote acceptor are to be maintained in 
the GD’s memory for a period of time without being added to the player’s credit balance, the 
storage of these messages shall be maintained in, and comply with, the critical memory 
requirements. The GD shall be able to recover these messages whenever it restarts, especially 
after a power failure, or similar event. 
8.4.19 The banknote acceptor device shall employ a reliable means of transmitting credit values 
to the GD. Pulse stream inte rface or serial communication without error detection and correction 
are not considered to be reliable communication methods. 
8.4.20 The banknote input system shall be constructed in a manner that protects against 
vandalism, abuse or fraudulent activity. As a guide the following might be tested: 
a) ability to prevent manipulation by the insertion of foreign objects into the banknote input 
system; 
b) ability to prevent easy alteration to the banknote path from the exterior of the GD without 
leaving evidence of physical modification of the device; and 
c) ability to deliver a banknote to the banknote storage receptacle. 
8.4.21 An alarm shall be raised for any of the following banknote acceptor specific conditions, 
unless done by staff authorized to do so and in accordance with an approved procedure: 
a) opening of the banknote acceptor area outer door (if separate from the GD main door); or DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xxix 
 b) opening of the banknote storage area door. 
8.5 Electronic funds transfer (EFT) 
8.5.1 All EFT systems whereby credits are transferred electronically to or from a GM shall be 
approved by the LA.  
8.5.2 If cards or other devices that employ a form of electronic storage of data are to be used, the 
TL shall be satisfied with all aspects of security. Some of the major concerns are: 
a) prevention of illegal or accidental alteration of data; 
b) protection from loss of data; 
c) recovery of information relating to damaged or lost storage devices (for example cards); 
d) accuracy of read/write operations; 
e) protection from fraudulent duplication of card information or credit balances; 
f) maintenance of all EFT transactions in a system log; 
g) recovery of all EFT transactions after failure of the system; and 
h) correct updating to the storage media and to the system of all electronic funds transactions. 
8.5.3 The GM shall maintain a record of, as a minimum, the last 10 successful EFT transactions. 
Each transaction record shall, as a minimum, include the date and time of the transaction and the 
actual amount transferred. It is acceptable if the information is only available from the MCS in an 
EFT environment. 
8.5.4 If EFT is used for gaming against a player account, no bet may exceed the available 
balance of an account. 
8.5.5 The GD card reader shall not accept an illicit card or a card that is not authorized for use. 
8.6 Credit redemption 
8.6.1 If a patron attempts to collect available credits, and the total coin value of those credits is 
less than the maximum CDD pay amount, the GD shall dispense the equivalent value in coins 
from the CDD. 
8.6.2 If a player attempts to collect available credits, and the total coin value of those credits 
exceeds the maximum CDD pay amount or, if after a CDD pay the patron attempts to collect any 
residual credits (for example, in a tokenized game), the GD shall either 
a) generate a validated ticket for cash redemption, or 
b) initiate a funds transfer to an appropriate player account, or 
c) automatically lock-up and go into a handpay or cancel credit, whereby the player is given the 
option either to receive a cancelled credit or to cancel the cancel credit and play out the remaining 
credits. 
8.6.3 Whenever credits are redeemed by a player, the number of credits paid out shall be clearly 
displayed (collect display) and shall be correspondingly removed from the credit display. In 
addition the monetary value of the amount redeemed may be displayed. DUS 1580-1 : 2014 
xxx © UNBS 2017  – All rights reserved  
 8.6.4 When there are "odd credits", or residual credits (i.e. less than the CDD base coin) in the 
player balance and a collect is attempted on a GD with a CDD, the GD shall pay out the balance 
as if it were a "large credit balance" (for example, by cash ticket or cancelled credit) instead of 
from the CDD. Alternatively, if a GD does not have this function, or if this function is disabled, 
there shall be a clear message on the GD in a prominent position, and in a font large enough to 
be easily read at a distance of three meters, that states that "This gaming machine does not pay 
out any credit amount less than <value>" (insert appropriate value in the message), or equivalent 
wording. 
8.7 Cashout by printed ticket 
8.7.1 A valid ticket shall contain the following information: 
a) the name of the licensed venue; 
b) the unique GD identification number; 
c) the current date; 
d) the time of day; 
e) the value of the credit in numbers and words; 
f) the unique identifying number of the ticket voucher; and 
g) the validation (checksum) number or bar code; note that the validation number computation 
method shall be evaluated by the LA and certified by the CA. 
8.7.2 Barcodes or other form of machine readable markings on a voucher shall have enough 
redundancy and error checking to ensure that 99,9 % of all misreads are flagged as an error. 
8.7.3 Ticket voucher printing, as a method of credit redemption, is only permissible where the GD 
is linked to a system or cash control system which allows validation of the printed ticket at a 
cashier station. Where a payout is by ticket voucher printed by the gaming equipment, the gaming 
equipment shall be capable of printing a ticket voucher for all credits owed to the player at the 
completion of each game. 
8.7.4 A ticket request shall be rejected by the system if the device that generates the ticket 
security feature is not able to issue such a feature, and the system shall initiate the appropriate 
error handling procedure. 
NOTE A security feature includes any mark, attribute or element (for example, a ticket number) 
that is added or attached to the ticket in order to allow the ticket to be validated . 
9.1 Source code 
9.1.1 General 
9.1.1.1 The following shall appear in all source code modules: 
a) the module name; 
b) the version number;  DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xxxi 
 c) the revision number; and 
d) a description of functions performed. 
The TL shall ensure that the program or source code modules have not been modified.  
NOTE This does not apply to commercially available software that has no effect on the game play 
or game result determination.  
9.1.1.2 So as not to complicate the validation of software, all individual device-specific information 
(for example, the GD identification number or address, the venue name and the touch screen 
calibration) and all device group-specific information (for example, jackpot configuration 
parameters) shall be stored separately from any common information (i.e. common to all GDs of a 
particular type). 
NOTE The intention here is that it should be possible to easily verify game software. Venue and 
other location specific information, date of compilation, etc., that may be included on the game 
software storage device (for example. EPROM or CD) make it impossible to obtain a signature 
that is common to all devices. 
9.1.1.3 Each GD shall have a function or program that displays the current software version(s) 
installed on the device. 
9.1.2 Control and upgrade 
9.1.2.1 Software media shall be clearly labelled, and shall contain sufficient information to identify 
the version and modification level. The identification used is at the discretion of the supplier but 
shall strictly follow the supplier’s identification system as detailed in the supplier's software 
configuration control procedures. 
9.1.2.2 Superseded approved versions of programs may be held on the storage media. However, 
it shall be possible to clearly identify which files belong to which version of the program. 
9.1.2.3 The method of loading programs to the storage media (for example, disk file transfer or 
down-line load) shall be certified by the CA. 
9.1.3 Verification 
9.1.3. 1 All program source codes for GMs shall be made available for examination. 
9.1.3.2 The party that submits software shall provide the wherewithal to demonstrate, or otherwise 
prove to the satisfaction that the source code supplied conforms to the same executable code as 
contained in the firmware program store of the GD submitted for certification. 
9.1.3.3 When compiled, all source codes supplied to the TL shall generate an object code that is 
exactly the same as that installed in the GD. 
9.1.3.4 If redundant sections of code exist in the program, the supplier shall provide an indication 
of the areas of code which are redundant. 
NOTE One way of achieving this goal is to use compiler directives that omit sections of code (for 
example, if a particular compiler option is set or not set). DUS 1580-1 : 2014 
xxxii © UNBS 2017  – All rights reserved  
 9.2 Critical memory requirements 
9.2.1 Critical memory 
Critical memory shall store all critical data. 
9.2.2 Maintenance 
9.2.2.1 To cater for disruptions that occur during the update process of critical memory, at any 
point in time during an update there shall exist sufficient information that allows the software to 
fully cater for such disruptions (for example, the software shall be able to identify the state of each 
copy of critical memory and recover from the most appropriate good copy to complete the update 
in each case of a disruption). 
9.2.2.2 The result of the critical memory validation shall be stored and kept always up to date (i.e. 
shall be updated after every instance of critical memory change). 
9.2.2.3 A validity check of critical data memory shall be undertaken at least before a game play. 
9.2.2.4 When meters in critical memory are being updated, the software shall ensure that errors in 
one copy of the meter readings are not propagated to other good copies. 
9.2.3 Detection of corruption 
9.2.3.1 Any failure of a validity check shall be classed as either 
a) recoverable memory corruption, if at least one copy of critical memory is established to be 
good, or 
b) unrecoverable memory corruption. 
9.2.3.2 A validity check of GD critical memory shall be undertaken at least after every restart of 
the device or transaction of significance (for example, logic door closed, door closed, parameter 
change or reconfiguration). After a device restart (for example, power off and on), the device shall 
complete its validity check of the critical memory area and then perform a comparison check of all 
good copies of critical memory. 
9.2.4 Recovery 
9.2.4.1 If the GD is so designed that after an uncorrectable memory corruption it is possible to 
view all copies of meters, the GD shall highlight which of these figures are expected to be good as 
opposed to those that might be corrupted. 
9.2.4.2 An unrecoverable memory corruption shall result in a RAM error. 
9.2.4.3 If an unrecoverable memory corruption occurs, it shall require a master reset. 
9.2.4.4 If validity checking of critical memory information fails, and data memory remains 
operational, the software could recover critical memory information in order to continue game 
play. 
This option has the following implications: DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xxxiii  
 a) all logical copies of critical memory shall be recreated using the good logical critical memory as 
a source; and 
b) the device shall verify that the recreation of the critical memory was successful before 
attempting to identify any permanent physical memory failure. If such permanent memory failure 
is determined, the device shall enter the unrecoverable memory corruption sequence. 
9.3 Program memory storage 
9.3.1 Labelling 
All program storage media shall be uniquely labelled, identifying the following: 
a) the program name (and the software shell name, if applicable); 
b) the name of the manufacturer; 
c) the development number or the variation; 
d) the version number; 
e) the type and size of media; and (if applicable), 
f) the location in the GD (if critical). 
9.3.2 WORM memory 
9.3.2.1 A WORM (for example, CD-ROM) used as a program or fixed data storage device shall be 
written such that only the actual program and data required are written to the WORM. 
9.3.2.2 The operational software shall provide an integrity check method to verify that there are no 
additional or missing programs or data records/files on the WORM. 
9.3.2.3 There shall be an ability to conduct an integrity check independent of the d evice’s 
operational software to verify that there are no additional or missing programs or data records/files 
on the WORM (for example, inserting a CD-ROM in another PC which then conducts a full 
signature check and directory search check over the CD-ROM space). 
9.3.2.4 The method of changing to different versions of the program, including reversion to old 
versions, shall be certified by the CA. 
9.3.3 Reprogrammable memory 
9.3.3.1 If a reprogrammable memory device is irreversibly configured at the hardware level as a 
read-only device (for example, the write line is cut off), it shall be treated for all purposes as an 
EPROM. 
9.3.3.2 A reprogrammable memory program storage device shall be protected from unauthorized 
modification. Modification shall only be permitted once the TL and the CA or the PLA (or both) are 
satisfied with the appropriate security measures (for example, if a high-voltage chip that allows 
modification of the reprogrammable memory devices is installed on the PCB). The method of 
securing the reprogrammable storage device shall be verified by the TL and certified by the CA on 
a case- by-case basis.  DUS 1580-1 : 2014 
xxxiv  © UNBS 2017  – All rights reserved  
 9.3.3.3 Before the termination of any programming operation on reprogrammable memory, each 
byte programmed shall be verified by a program comparison controlled by the programming 
device. 
9.3.3.4 Only the actual program and fixed data required shall be written to the reprogrammable 
memory device. 
9.3.3. 5 Jumpers or similar devices can be used to enable or disable erasure or writing to 
reprogrammable memory provided there is a feedback signal to the software so that the setting of 
the jumper position can be recorded or appropriately acted upon. If a jumper or a switch is set to 
"Write", then the GD shall not be able to enter "Play" mode. These jumpers shall be located within 
the logic area of the GD. 
9.3.3.6 All reprogrammable memory devices shall be housed in a secure area. 
9.3.4 Read/write storage 
9.3.4.1 A read/write storage device (for example, a disk or a tape) used for storage of program or 
fixed data shall be written in such a way that only the actual program and fixed data required by 
the program are written to the storage device. 
9.3.4.2 The operational software shall provide an integrity check method to verify that there are no 
additional or missing programs or fixed data records/files on the storage device. 
9.3.4.3 There shall be an ability to conduct an integrity check independent of the device’s 
operational software to verify that there are no additional or missing programs or data records/file s 
on the storage device. 
9.3.4.4 All methods of integrity checking shall have the ability to identify files/records that contain 
variable data and exclude them from the signature calculation. 
9.3.5 ROM program storage 
All unused areas of ROM shall be written with the inverse of the erased state, which for most 
EPROMs are zero bits (00 hex), rather than one bits (FF hex). 
9.3.6 Verification 
9.3.6.1 All non-critical memory RAM shall be checked for corruption at each power up. 
9.3.6.2 All devices that contain program memory or critical memory shall be validated by software. 
This validation may include self-checking by specific devices with internal programs. RAM and 
program storage device space that is not critical to GD security need not be validated. 
9.3.6.3 Memory that does not change dynamically (for example, EPROM) shall be validated by 
the GM a t least every time the hardware is reset (for example, at power on), every time the 
software is reset (where this is possible) or after a type 4 significant event. Failure of the validation 
shall be reported to the MCS, if possible.  DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xxxv 
 NOTE 1 Equipment in a casino environment is not required to be capable of doing signature 
checking in response to a request from the MCS. 
NOTE 2 The fact that the GM activates normally is deemed to be proof that validation was 
successful.  
9.3.6.4 If a validity check of the software fails, it is understood that this means that the GD cannot 
function, in which case it shall disable itself immediately. 
NOTE Excludes transaction devices that do not influence the game results. 
9.3.6.5 The integrity of the operation of the device shall be protected from nefarious or accidental 
use of the unused portions of the program memory storage media. 
9.4 Rand om number selection process 
9.4.1 General 
9.4.1.1 The method of Random number generation is not mandated. A pseudo-random number 
generating algorithm, a dice shaker, a selector of keno balls, or a roulette wheel, etc., can all be 
acceptable RNGs where these comply with the CA’s requirements.  
9.4.1.2 If a software-based RNG is used, the choice of algorithm is at the discretion of the supplier 
of equipment. 
9.4.1.3 If, for any reason, the background RNG activity is interrupted (for example, in the case of 
GD power down), it shall not be possible for the next input variable(s) for the RNG to be 
duplicated (i.e. in different GDs). The method of generating the next input variables under these 
circumstances shall be evaluated by the TL and certified by the CA. 
9.4.1.4 RNG tests that might be applied include the following: 
a) the chi-square test; 
b) the equi-distribution (frequency) test; 
c) the gap test; 
d) the poker test; 
e) the coupon collector’s test; 
f) the permutation test; 
g) the run test (patterns of occurrences shall not be recurrent); 
h) the spectral test; 
i) the serial correlation test potency and degree of serial correlation (outcomes shall be 
independent from the previous game); and 
j) a test on subsequences DUS 1580-1 : 2014 
xxxvi  © UNBS 2017  – All rights reserved  
 9.4.2 RNG requirements 
Game software shall generate random symbols from an RNG that uses a mapping algorithm. The 
fundamental requirement is that the use of an RNG shall result in the selection of game symbols 
or the production of game outcomes that can be proven to ensure that: 
a) the output of the symbols from the RNG is not predictable, 
b) any outcomes derived from the RNG are uniformly distributed, 
c) any mappings to convert random numbers into game symbols are linear, and the distribution of 
the mapped symbols is identical to the distribution of the unmapped random number from which 
they were derived, 
d) the mapped random number sequence shall demonstrate that they are statistically random 
when subject to the same statistical tests for randomness specified for the base RNG, and 
e) the game outcomes, which are derived from either a combination of mapped symbols or 
directly from the unmapped random numbers, shall have the same distribution and probability of 
occurrence as the game that the machine implements. In particular, poker games shall have the 
same first hand distribution and probability as hands dealt from a randomly shuffled deck of cards; 
spinning reel games shall have the same outcome probabilities and outcome distribution as the 
physical model upon which the game is based, and so on. 
9.4.3 Background RNG activity 
9.4.3.1 The mapping of numbers directly from the RNG output or through a scaling algorithm shall 
not influence a symbol to occur with a probability not equal to its statistical expectation. 
9.4.3.2 If a random number with a range shorter than that provided by the RNG is required for 
some purpose within the GD, the method of re-scaling, i.e. converting the number to the lower 
range, shall be so designed that all numbers within the lower range are equally probable. 
Following a low probability game outcome (for example, a jackpot win, a major prize win, or a 
particular graphic game result presentation), where that game outcome is represented by only 
one RNG value or a small number of RNG values, it is important that subsequent game play on 
that machine is unpredictable. That is, the machine does not subsequently go through one 
defined sequence of game outcomes, or one of only a few possible sequences of game 
outcomes. In such implementations the period of the RNG shall be much greater than its range. 
9.4.3.3 Requirements for background RNG activity are as follows: 
a) the RNG shall be cycled continuously between games; and 
b) when a game feature is initiated, random numbers for that feature shall be selected from the 
RNG. 
NOTE The game software does not determine the outcome of a play (critical to the game result) 
or gamble feature until after all player options that pertain to the play or gamble feature have been 
made. Choice of player options cannot affect RNG values. DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xxxvii  
 9.4.3.4 Seeding of the RNG is subject to the following requirements: 
a) the method of seed generation shall ensure that the same sequence of random numbers is 
never used in more than one device at the same time; 
b) the "next" game outcome is not able to be predicted; and 
c) seeding and re-seeding shall be kept to an absolute minimum. 
9.4.3.5 If a particular random number selected is outside the range of equi-distribution of re-
scaling values, it is permissible to discard that random number and select the next in sequence for 
the purpose of re-scaling. 
9.5 Information display 
9.5.1 Display methodology 
9.5.1.1 External displays employed in communicating the results of games shall be certified on a 
case- by-case basis by the CA. 
9.5.1.2 The method of display of information, including game outcome, shall be certified by the 
CA. 
9.5.1.3 Symbols of virtual reel games (video) shall appear to the player in the same arrangement 
as per the reel strips. The order of the reel’s symbols displayed to the player shall not be 
manipulated or rearranged. 
9.5.2 Recovery 
In the event of a non-destructive fault or failure, deactivation or interruption, the GD shall be able 
to recover with no loss to the player or of critical data to the monitoring and control system. An 
error catching routine shall exist that prevents the GM from displaying a win amount that exceeds 
the maximum payout displayed on the pay table, except when participating in a jackpot.  
9.5.3 Last game information 
9.5.3.1 All GMs shall be capable of storing and displaying last game data for at least the five most 
recently played games. 
9.5.3.2 The following information on the last game played (the game before the current game) 
shall be retrievable: 
a) the type of game played; 
b) the award table used; 
c) display card values, reels in position, or other game status information; 
d) the total number of credits or monetary value at the start of the game (less credits bet); 
e) the total number of credits or monetary value played; 
f) the player choices (if any) involved in the game outcome; 
g) the total number of credits or monetary value associated with the award resulting from the last 
play (win); DUS 1580-1 : 2014 
xxxviii  © UNBS 2017  – All rights reserved  
 h) the total number of credits or monetary value added after the last game; 
i) the total number of credits or monetary value collected or cancelled after the last game; 
j) a display of all feature games following the last game display (if possible). Otherwise at least the 
me tering information shall be preserved; and 
k) the jackpot amount (if any) and an indication if won or not. 
9.5.3.3 In the case of a stepper motor GD, this means spinning the reels to the final resting point 
at the completion of the game and illuminating or flashing any lights or other indicators that were 
illuminated or flashing at the end of that game. The wheels, lights and display shall be returned to 
their original states when the viewing of the last game replay is completed. 
9.5.3.4 In the case of spinning reel games, the GD shall display at least the final resting place of 
the reels, the options (play lines or number of coins selected (or both)) and an indication of 
winnings, in a way similar to that originally shown to the player. 
9.5.3.5 In the case of keno and bingo games, all of the balls drawn, the selections made by the 
player and the final result shall be displayed in a way similar to that originally shown to the playe r. 
9.5.3.6 In the case of card games, all cards dealt in a game shall be shown on the screen. In the 
case of poker or any other game with a hold/discard strategy it is necessary to show the symbols 
or cards held and those discarded. 
9.5.3.7 The units in which each statistic is measured shall be certified by the CA. 
 
9.6 Prescribed display formats 
9.6.1 If dates and times are displayed, they shall be displayed in a consistent format. 
9.6.2 The only acceptable all-numeric date formats are yyyy- mm-dd and dd- mm-yyyy.  
NOTE 1 The preferred date format is yyyy- mm-dd.  
NOTE 2 This requirement does not apply to the date format on displays that are not accessible to 
the player, such as set-up screens.  
9.6.3 Only 24-hour time formats are acceptable. 
9.6.4 Field separators within times shall be colons ( : ) or full stops ( . ). Time of day shall be given 
as East African standard time. 
9.7 Communication 
9.7.1 If there is a failure of a communication link between the GD and the next point in the 
monitoring system (i.e. the inability to send or, where applicable, to receive messages to/from the 
monitoring and control system) then, when communication is restored, the GD shall check 
whether there was a configuration or software change. If there was, the GD shall send a 
significant event message as soon as possible after reactivation, but before permitting any game 
to be played. DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xxxix  
 9.7.2 If the GM is unable to send messages to the monitoring and control system, then the GM 
may complete the current game and permit cashout but shall then disable further game play until 
able to forward these messages to the monitoring and control system. 
9.7.3 All GDs shall be able to handle the following range of failures without loss of data: 
a) failure of the central computer LAN interfaces; 
b) fai lure of the central LAN; 
c) failure of central data communication interface devices; 
d) failure of single data communication interface; 
e) high data communication error rates on line; 
f) a foreign or additional device placed on a LAN; 
g) a foreign or additional device placed between LAN bridges, communication controllers, or on 
data communication lines between sites; 
h) single data communication port failure on remote controller (if any); 
i) LAN failure on regional or local controller (if any); 
j) LAN failure on cashier terminal (if any); and 
k) data communication interface failure on a GD. 
9.7.4 Jackpot or progressive jackpot controlling devices shall communicate with the monitoring 
and control system by means of a protocol-based form of communication. This does not apply to 
standalone jackpot or progressive controllers.  
9.8 Metering – Reports and displays  
NOTE It is the intention of this sub-clause to have a common designation for the values on reports 
or shown on-screen. It is not intended to refer to designations used in any protocol or messaging 
system. 
9.8.1 Unless otherwise specified in legislation (see foreword), the value displayed by the meter 
may be in either credits or in monetary values (i.e. Uganda shillings and cents) as long as the 
units used are clearly shown near to the meter or display.  
9.8.2 The "total bet" meter is defined as the total value of all credits bet. 
It shall be designated on all reports or displays as "Total Bet".  
In the case of multigame GMs this meter is also required and a separate value shall be 
maintained 
for each configured game on the GM. 
9.8.3 The "total win" meter is defined as the total value of all credits won. 
It shall be designated on all reports or displays as "Total Win". Amdt 2 
In the case of multigame GMs this meter is also required and shall be maintained for each 
configured game on the GM. DUS 1580-1 : 2014 
xl © UNBS 2017  – All rights reserved  
 9.8.4 The "total coin box drop" meter is defined as the total value of coins or tokens to the coin 
box drop of the GD. 
It shall be designated on all reports or displays as "Total Coin Box Drop".  
An additional period meter is required in audit mode that can be reset following each clearance of 
the coin drop storage area.  
9.8.5 The "total bill drop" meter is defined as the total value of all bills entered into the bill acceptor 
connected to the GD. 
It shall be designated on all reports or displays as "Total Bill Drop".  
An additional period meter is required in audit mode that can be reset after each clearance of the 
bill storage area.  
9.8.6 The "total games played" meter is defined as the total number of games started and 
completed on the GD. The units shall be in games. 
It shall be designated on all reports or displays as "Total Games Played".  
In the case of multigame GMs this meter is also required and shall be maintained for each 
configured game on the GM. 
9.8.7 The "total hand pay" meter is defined as the total value of all hand pays, including hand 
pays less than one coin or token, hand pays greater than the CDD limit, and any printed tickets 
and vouchers. 
It shall be designated on all reports or displays as "Total Hand Pays".  
If a GM keeps separate meters for "cancel credits", "voucher out" or "hand pay with jackpot" then 
the summation of these meters to derive a total amount for "Total hand pays" may be done by the 
MCS.  
9.8.8 The "total cash in" meter is defined as the total value of all cash entered into the GD 
(including amounts transferred from a card in an EFT environment). 
It and shall be designated on all reports or displays as "Total Cash In". Separate meters for 
"cash", "EFT transactions" and "tickets/vouchers" that must be added in order to derive the "total 
cash in" amount are acceptable.  
9.8.9 The "total cash out" meter is defined as the total value of all cash paid out of the GD 
(including hand pays, printed tickets and vouchers and amounts transferred to a card in an EFT 
environment). 
It shall be designated on all reports or displays as "Total Cash Out". Separate meters for "cash" 
"EFT transactions" and "tickets/vouchers" that must be added in order to derive the "total cash 
out" amount are acceptable.  
9.8.10 The "total EFT in" meter is defined as the total value of all credits transferred from a card to 
a GD in an EFT environment. DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xli 
 If the GD has an EFT functionality, this shall be designated on all reports or displays as "Total 
EFT In". If the GD does not support EFT, this meter is not required.  
9.8.11 The "total EFT out" meter is defined as the total value of all credits transferred to a card 
from a GD in an EFT environment. 
If the GD has an EFT functionality, this shall be designated on all reports or displays as "Total 
EFT Out". If the GD does not support EFT, this meter is not required.  
9.8.12 The "last five bills in " display shall enable the GD to display, in audit mode, the shillings 
value of each of the last five bills entered into the bill acceptor. The bills shall be listed in the order 
they were entered, with the most recently entered bill listed first. 
9.8.13 A meter or display shall be updated and recorded by the monitoring and control system as 
the event or transaction occurs. All meters shall be added to, not incremented, with the exception 
of coin-handling meters (i.e. coin-in and coin-out meters) which may be either added to or 
incremented. The term "added to" indicates the fetching of the current value from memory, 
conducting an arithmetic-add operation and storage of the result in memory. 
9.8.14 When a meter, of any type, reaches its maximum value, it shall automatically revert (i.e. 
"wrap round") to zero and subsequently continue counting (from zero) in the normal way. 
9.8.15 Gaming equipment shall have access to a function that enables the display of all metered 
information retained by the gaming equipment. It is not mandatory that metering information be 
displayed on the device from which the information originates. The information may be displayed 
on an external device or on a computer (or on both) to which the GD has communicated such 
information. 
9.9 Metering – Player displays 
9.9.1 A GD shall be able to display the information given in 8.9.2 to 8.9.20 to the player (as 
applicable to either "EFT" or "non-EFT" environments). Note that this does not prevent more than 
one piece of information being presented on the same display unit, provided that the associated 
artwork is not deemed to be misleading.  
9.9.2 The "credit display" shall display the current number of credits available to the player under 
the heading "Credits". This display shall be updated immediately after each bet is made and at the 
end of the game when it shall be increased by the value displayed by the "Win" display. It is 
acceptable to additionally display the shillings value if desired. 
9.9.3 The "bet display" shall display the cumulative total number of credits bet by the player during 
the current game to the player under the heading "Bet". This display shall be updated at the start 
of each game. It is acceptable to additionally display the equivalent shillings value if desired. 
9.9.4 The "win display" shall display the (cumulative) number of credits won for each win won by 
the player during a single game (and therefore the prize that has been won at the completion of 
each game) to the player under the heading "Win". This display shall be updated at the DUS 1580-1 : 2014 
xlii © UNBS 2017  – All rights reserved  
 occurrence of each new win, and at the start of each game. It is acceptable to additionally display 
the equivalent shillings value if desired. 
9.9.5 The "collect display" shall display the number of credits collected from the GD by the player 
under the heading "Collect" or "Paid". This display shall be updated each time the player collects 
credits from the GD (whether by CDD, hand pay, printed ticket or voucher, or EFT card) and at 
the start of each game. It is permissible to display, in addition to the credit amount, the equivalent 
Uganda Shillings value, if desired. 
9.9.6 Player displays may be incremented or decremented (for example, stepped) to the value of 
the actual meter for visual effect. However, the value contained in the internal storage of these 
displays shall be immediately increased (not incremented or decremented over a period of time). 
8.9.7 The number of credits collected shall be subtracted from the player's credit display. 
9.9.8 The value of the win display shall only be added to the player’s credit display.  
9.9.9 The player's credit display shall always be prominently displayed in all modes except audit, 
configuration and test modes. During play in second screen bonus features, the player’s credit 
amount does not need to be displayed, provided that the player is not required to bet additional 
credit s during the feature. 
9.9.10 The player’s credit display shall have sufficient digits to allow the display of at least twice 
the credit value of the maximum prize. Tokenization and denomination configurable parameter 
options shall not permit credit values that are greater than the above to be displayed. 
9.9.11 Whenever credits are bet (for example, at the commencement of the game or in the event 
of additional wagers during a game) the number of credits bet shall be immediately subtracted 
from the player’s credit di splay and displayed on the bet display. 
9.9.12 It is mandatory for a multigame GD to show the monetary value of the player's available 
credits on the game select screen. The monetary value of the player's available credits may also 
be shown on each game play screen in addition to the player's available credits for that game. 
This requirement is optional for a single game machine. 
9.9.13 If the current shillings amount is not an even multiple of the tokenization factor for a game 
or if the credit amount has a fractional component, the credits displayed for that game may be 
displayed and played as a truncated amount (i.e. fractional part removed). However, the fractional 
credit information shall be made available to the player when the truncated credit balance is zero 
or on the game select screen. 
9.9.14 At least the following displays shall be able to be shown separately for each game offered 
on a multi-game GM: 
a) the total of all credits bet; and 
b) the total of all credits won. 
9.9.15 Prize determination shall DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xliii 
 a) be clearly specified on the display or on the exterior of the device, or be easily accessible to the 
player, and 
b) be exclusively a consequence of the outcome of a computer based RNG in conjunction with the 
prevailing payout table and rules of the game. 
9.9.16 There shall be a game selection screen where the full amount of the player’s credit balance 
is displayed either in shillings and cents or in credits. 
9.9.17 Only credits taken as wins by the player or automatically credited by the GD shall be added 
to the "Win" meter. 
9.9.18 When residual credits are played off, credits bet shall be added to the "Total bet" meter. 
9.9.19 When residual credits are played off, and if any credits are won, the value of the win shall 
be added to the " Total win" meter and shall either 
a) increment the player’s credit meter, or  
b) be automatically dispensed, and the value of the coin(s) added to the "Coins out" meter. 
9.9.20 The value of every prize (at end of game) shall be added to the credit display, except 
progressives. Progressives may be added to the credit display if either 
a) the credit display is maintained in shillings and cents, or 
b) the progressive display is incremented to whole credit amounts, or 
c) the prize in shillings and cents is converted to credit s on transfer to the player’s credit display in 
a manner that does not mislead the player (for example, make unqualified statement "wins display 
amount" and then round down on conversion) or cause accounting imbalances. 
9.10 Labelling 
All non-mandatory, retrievable electronic statistics or other information shall be suitably labelled. 
9.11 Simulator 
If a simulator is provided to enable development of the protocol in GDs and other gaming 
equipment that interface with the protocol and assist in the testing of the GDs by other suppliers, 
the TL and the CA, then the simulator shall 
a) adequately support and execute all transactions and message types that are used by the 
protocol; 
b) have a function to thoroughly check every requirement, behaviour, function or feature the 
protocol dictates; 
c) run on standard, freely available equipment such as a personal computer or the equivalent; 
alternatively, the supplier of the protocol shall loan, on request, suitable hardware on which the 
simulator can operate, to suppliers of GDs; and  
d) be provided, together with all relevant documentation, on request to all users  
 DUS 1580-1 : 2014 
xliv © UNBS 2017  – All rights reserved  
 10 Operational requirements 
10.1 Access to restricted features 
Access to the following restricted features of gaming equipment shall be regulated by at least a 
key switch, or by key-based access to the inside of the machine cabinet:  
a) auditing information; 
b) statistical information; 
c) test functions; and 
d) any other features deemed by the PLA to be restricted.  
10.2 Set- up – Device configuration 
10.2.1 Configuration of variables 
10.2.1.1 A variable required to be set during device configuration or set-up shall not be able to be 
changed except following a valid memory clearance, unless able to be changed by some other 
secure method certified by the CA. 
A GD shall not be able to be operated unless all configuration variables are set. 
A dev ice may be configured remotely or by direct access by means of an approved mechanism. 
If memory becomes corrupted, a GD shall not assume default values and recommence gamin g 
operation unless the assumed values have been configured by an approved mechanism. 
10.2.1.2 A gamble feature bet option shall only be enabled or disabled in setup mode and the 
appropriate configuration change significant event shall be generated. 
10.2.2 Reconfiguration 
10.2.2.1 The GD may be reconfigured to modify the following parameters, but only by a secure 
approved method: 
a) the mapping of random numbers to cards or symbols; 
b) the game or sets of games approved for play; 
c) denomination and tokenization; and 
d) the paytable. 
10.2.2.2 All configuration settings required for the proper operation of the GD shall be entered 
before the GD can enter "Play" mode. If all configuration settings required have not been entered, 
the GD shall detect this condition and remain disabled. 
10.3 System security 
10.3.1 The set of games offered to the player for selection, or their paytables, may be changed 
only by a secure approved method. No changes to the set of games offered to the player for 
selection (or to their pa ytables) are permitted while there are credits on the player’s credit meter 
or while a game is in progress. DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xlv 
 NOTE The intention is to prevent any modification to the selection of games offered, or to their 
paytables, as the result of player history. The player may switch between any games offered 
without terminating the session. 
10.3.2 Gaming equipment shall disable all player inputs and suspend all gaming functions while 
any of its secure area doors are opened or remain open. 
10.3.3 Gaming equipment shall not have any functions or parameters adjustable by or through 
any separate computer, input device or input codes, except for the following: 
a) the adjustment of features that are wholly cosmetic (i.e. that do not affect functionality in any 
way); 
b) the downloading in an authorized manner of any software, data or operational parameter; and 
c) an approved configuration (set-up) mode. 
10.3.4 In general, the reactivation of a GM that has been deactivated shall require manual 
intervention by the gaming venue operator or the system operator. The following exceptions 
apply: 
a) if a door open event occurs other than a logic door open, the GM may reactivate automatically 
when the door is eventually closed; 
b) if the PIN retry limit is exceeded for a player’s account card, the GM shall remain deactivated 
until the card is removed; and 
c) if the power supply to a GM fails, the GM is deactivated as a matter of course. It is permitted for 
the GM to automatically reactivate itself unless it determines that there was a configuration or 
software change while the power was down, in which case the GM shall remain deactivated until 
manually reactivated. 
NOTE  The venue operator may choose to require manual reactivation in all cases. 
10.3.5 Where a GD is unable to operate without the loss of any information (for example, 
metering, transactions or significant events), it shall immediately disable any further game play. 
10.3.6 If a significant event has not already been logged (by the system or the GD) when 
deactivation occurs, the GD shall ensure that such an event is reported to the system as soon as 
possible. 
10.4 Master reset 
10.4.1 Following the initiation of a master reset procedure (using an approved RAM clear 
method), the game program shall execute a routine which initializes each and every bit in RAM to 
the default state. 
10.4.2 It shall not be possible to reset any critical RAM without first accessing the logic area. 
10.4.3 The default reel position or game display after a master reset shall not be a winning 
combination on any selectable line. The default game display upon entering game play mode 
shall also be a non-winning game. DUS 1580-1 : 2014 
xlvi © UNBS 2017  – All rights reserved  
 NOTE The selection of a specific "default" combination that is displayed after every reset is 
acceptable, as long as it is a non-winning combination (i.e. it need not be selected at random ). 
10.4.4 A configuration setting that is required to be entered during set-up mode immediately 
following a master reset shall not be able to be changed after the machine leaves set-up mode. 
10.5 Door open procedures 
The following procedures shall be performed on the occurrence of any door open: 
a) any software state prior to door opening shall be saved; 
b) any game play shall be saved in its current incomplete condition; 
c) if mechanical reels are spinning prior to the door opening, the reels shall continue spinning after 
the door is closed; 
NOTE There should not be a false impression created that the game achieved a result while the 
door was open, or just prior to the door being opened. 
d) credit input shall be disabled (may be re-enabled for the duration of a credit input test or CDD 
test); 
e) the machine shall clearly indicate that the door has opened and game play is not possible; 
f) if in CDD payout, the CDD shall be turned off and the brake applied (may be re- enabled for the 
duration of a CDD test); 
g) all player inputs that can affect a play in progress shall be disabled (unless used in door 
open/test mode); and 
h) cashout of any kind to players shall be disabled.  
10.6 Door close procedures 
When any door is closed the software shall return to the condition prior to when the first door open 
state occurred, except when the GM detects that there has been a configuration or software 
change, in which case it shall send the appropriate message to the MCS. This means that:  
a) a message or other indication stating that the door has closed, or other indication (i.e. such as 
the disappearance of a message or indication stating that the door was opened) shall be 
displayed; this may be for a preset period or until the next game play, b) any relevant player 
inputs shall be re-enabled, 
c) the alarm shall be turned off, and  
d) any incomplete game play when the event occurred shall recommence from the beginning of 
the play or from the point at which interruption occurred and conclude normally, using the data 
that were saved previously. 
10.7 Audit mode 
10.7.1 It shall always be possible to enter audit mode when the GD is in idle mode. DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xlvii 
 10.7.2 The device shall not be playable while auditing information is being displayed on the 
device.  
10.7.3 It is not mandatory that auditing information be displayed on the device from which the 
information originates. The information may be displayed on an external device or on a computer 
(or on both) to which the GD has communicated such information. 
10.7.4 It is preferred that all non-game specific player displays (for example, credit display, win 
display, bet display and collect display) are displayed in the same position for all games. 
10.7.5 Audit mode shall include as a minimum, the following items: 
a) display of all electronic meter and display information; 
b) last game replay; 
c) display of GM identification (i.e. the identification number that uniquely identifies the GM to the 
monitoring and control system); and 
d) display of software or game identification, or both. 
10.8 Demonstration mode 
10.8.1 Demonstration mode (where implemented) may only be entered into by means of an 
approved secure method evaluated by the TL and certified by the CA, and only while a) the main 
door is open; and 
b) the GD is on-line to a data controller unit or bank controller. 
10.8.2 While the GD is operating in the demonstration mode, there shall be clear notification that 
the GD is in that mode (for example, by tower light signal or on-screen message) and the main 
door of the GD shall be open at all times. 
10.8.3 If soft meters are incremented in the demonstration mode, such credits shall be 
automatically cancelled upon the change of the GD from demonstration mode to game-play 
mode. 
10.8.4 A GD in demonstration mode shall not be capable of being used as an off-line GD. 
Some suggested implementations which might help prevent such illegal activity, are: 
a) not to allow coins to be entered into the GD (i.e. lockout) except in accordance with approved 
coin test procedures; 
b) not to allow any coins out for credits in the GD except in accordance with approved CDD test 
procedures; 
c) to provide a spot on a touch screen or to interpret a button that shall credit the GM with a 
number of coins; 
d) if a "ticket" cashout is allowed, to clearly mark the ticket that is printed as a non-valid ticket, 
including a non-valid serial number (for example all zeroes or nines); and 
e) if the main door is closed, to let the GD immediately exit demonstration mode and return to 
game-play mode. DUS 1580-1 : 2014 
xlviii © UNBS 2017  – All rights reserved  
 10.9 Idle mode 
10.9.1 While the GD is in idle mode, if there are credits showing on the credit display, the 
following shall remain on view until the next play: 
a) the bet display for the last play; 
b) the final reel stop positions, card values, etc. for the last game play; and 
c) the win display from the last play (unless a payout has occurred since completion of the last 
game play, and the "win" display has been used as a "collect" display). 
10.9.2 During idle mode, if a payout has occurred since the completion of the last game play, the 
collect display that represents the payout shall be displayed. If multiple payouts have occurred 
since the last play, the collect display of the last payout only shall be displayed. Additionally, the 
cumulative payout amount may be displayed. 
10.9.3 Multigame GDs may have a "Game select" mode entered from "Idle" mode where the 
above information is not required to be displayed. If "Game select" mode is entered, it is 
necessary to display all of the information above when the same game is selected again (except 
as in 9.9.2 above). 
10.10 Test/service mode 
10.10.1 While the GD is operating in the test mode, there shall be clear notification that the GD is 
in that mode (for example, by tower light signal or on-screen message). 
10.10.2 Opening the main cabinet door of the GD may automatically place the GD in a service or 
test-mode. A test/diagnostics mode may also be entered by means of an appropriate instruction 
from a n attendant during an "Audit" mode access. 
10.10.3 If there are any test-mode states which cannot be automatically cancelled by closing the 
door (for example, if it is first necessary to manually set a switch) or exit from the "Audit" mode (if 
that was the method of entry to the "Test" mode), the action necessary shall be indicated on the 
machine and in the relevant manuals. 
10.10.4 Test games, if implemented, shall 
a) not increment any meters, other than a temporary on-screen credit display; 
b) only be available after entering a specific test game mode within door open mode; and 
c) be clearly indicated as not in normal game play mode. 
10.10.5 The following information shall be accessible in test mode if not available in audit mode: 
a) the revision number for the game (and if applicable, base) software in the machine; 
b) set-up/configuration data; and 
c) the expected RTP. 
10.10.6 If a CDD test is implemented that does not require the door securing access to the CDD 
to be opened, no meters that are used to calculate revenue shall be affected. 
10.10.7 If a "coin in" validation test is provided, the following conditions shall be met: DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  xlix 
 a) the number of coins accepted as valid by the CAD shall be displayed; 
b) the number of coins that pass coin direction sensors shall be displayed; and 
c) no meters shall be affected. 
NOTE Alternative implementations such as providing indicators of the line status (jammed, 
activated, faulty, etc.) of the validator outputs and diverter outputs are acceptable if at least the 
same level of diagnostics is achieved. 
10.10.8 Coins shall not be capable of being paid out other than 
a) by normal play, unless in CDD test mode; or 
b) by a CDD dump function. 
10.10.9 If there is a possibility that credits can be obtained whilst the machine is in test mode, 
those credits shall be automatically cancelled when the door is closed and shall not be credited to 
the meters. 
10.10.10 When the GD is in test, demo or service mode, the current play-mode status of the 
game, including player's credit, shall be preserved. 
10.10.11 Where the possibility exists to obtain credits whilst the door is open for any purpose (for 
example, coin-in test) including the service mode, such credits shall be automatically cancelled 
when the door is closed and shall not be credited to any meters. 
1.10.12 A message or code indicating that the machine is in test, demo or service mode shall be 
clearly displayed. 
10.11 Power save mode 
10.11.1 If a GD has a "Power save" mode it shall only be activated when the GD has been idle for 
a period of time not less than 5 min, or when the GD is in a disabled state. 
For the purposes of this sub-clause, a GD shall be defined as being "idle" if, for the nominated 
duration, it 
a) does not have any key switch activated (for example, accessing "Audit" mode); 
b) does not have any door open; 
c) has no credits on the pla yer prize display yet to be transferred to the player’s credit display;  
d) has not had any coins or banknotes input; 
e) has not had its touch screen touched; 
f) has not had any button pressed; 
g) does not have any fault condition; or 
h) does not have any electronic funds transfer or credit transfer to or from the GD pending. 
NOTE 1 Power save mode should be capable of being enabled or disabled by staff by means of 
set-up mode, or by means of the monitoring system (if applicable). 
NOTE 2 Power save mode may be activated manually (i.e. by means of an auxiliary power switch 
or key switch) and in this case the conditions listed above are void. DUS 1580-1 : 2014 
l © UNBS 2017  – All rights reserved  
 10.11.2 While in "Power save" mode, power may be removed from the coin diverter, incandescent 
display, monitor and all fluorescent lights. Critical security functions of the GD shall still be 
performed. 
10.11.3 The GD shall exit from "Power save" mode and return to the normal display mode 
immediately upon it ceasing to be "idle" (if not using a manual power save implementation). 
10.12 Mechanical reels and wheels 
10.12.1 Microprocessor-controlled reels (for example, stepper motor reels) shall automatically re-
spin to the last legally obtained play-mode result when the play mode is re-entered (for example, 
when the main door is closed, power is restored, audit mode is exited, or when a fault condition is 
cleared). 
10.12.2 Reel bounce and float shall be prevented when a spinning reel is being stopped. 
10.12.3 Each microprocessor-controlled reel shall spin at least one revolution per play unless 
stopped by player intervention as provided for in the rules of the game. 
10.12.4 A reel or a wheel assembly shall be so designed that the spin of each reel is not 
obstructed by any other component. 
10.12.5 Microprocessor-controlled reels shall be monitored to detect malfunctions such as a reel 
that is jammed, or is not spinning freely, or has failed to stop, or any attempt to manipulate its final 
resting position. 
10.12.6 The control of electromechanically controlled display devices, such as spinning wheels 
and roulette wheels, shall be sufficient to enable the system to detect a malfunction or an attempt 
to interfere with the correct operation of that device. This may also be achieved by a last game 
recall facility. 
10.12.7 Reel assemblies shall have a clearly identifiable reference point at which the start of the 
strip symbol artwork is located. 
10.12.8 Reel assemblies shall be so constructed that winning symbol combinations match up with 
the pay lines. 
10.13 Video displays 
10.13.1 An attract mode may be used, as long as the information required while in idle mode is 
displayed after the attract mode has completed its cycle. 
10.13.2 If the display is over-written by the paytable, on restoration of the game screen the same 
display, that shows the winning combination resulting from the last game played, shall be suitably 
highlighted. 
10.13.3 Screen save functions are subject to the following constraints: 
a) any screen save function shall only be activated when there are no credits on the machine; 
b) if a fault condition exists on the machine when the program enters the screen save function, the 
nature of the fault shall be displayed, otherwise the machine shall exit the screen save; and DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  li 
 c) the screen save mode shall cease upon the occurrence of any of the following: 
1) the activation of an input device; 
2) any door opening; or 
3) an error event condition. 
10.13.4 Touch screens, if used, shall comply with the following: 
a) touch screens, which are accessed by the general public, shall be resistant to scratching from  
conditions likely to occur during normal use; 
b) touch screens shall be accurate, and once calibrated, shall maintain that accuracy for at least 
the manufacturers recommended maintenance period; 
c) touch screens shall be designed and installed such that static build-up is minimized to a level 
that ensures no humanly perceptible static is discharged through a grounded patron that touches 
the screen; 
d) GDs that employ touch screens shall have a recalibrating facility that may be either manual or 
automatic, but in any case shall not require access to a logic area; 
e) touch screen selected input shall always be interpreted accurately and acted upon in 
accordance with the description of the choice (indicated on the screen) made by the player; 
f) if the opening of the GD door is found to affect touch screen calibration and recalibration is 
carried out with the door open, there shall be in place means to ensure that the recalibration is 
correct when the door is closed (for example, two sets of calibrations: one for door open and one 
for door closed); 
g) touch screen button icons shall be sufficiently separated to reduce chances of the wrong icon 
being selected due to incorrect calibration or parallax errors; and 
h) all buttons and touch points shall be documented for evaluation by the TL and certification by 
the CA. 
10.14 Electronic funds transfer system 
A GM shall retain a card used for EFT gaming within the card reading device, once inserted, 
except if an amount debited from the card is placed directly on the credit meter and no further 
transactions are required from the card (for example, updating of account balance or credit out). 
The GM shall not release the card until one of the following conditions are met: 
a) a player has requested a collect of remaining credits and all updating of account records or 
information (or both) has been successfully completed; 
b) a player has a zero credit balance and all updating of account records or information (or both) 
has been successfully completed; 
c) an invalid card event condition has been cleared by an approved method; or DUS 1580-1 : 2014 
lii © UNBS 2017  – All rights reserved  
 d) power or communications failure (except that, if conditions (a) and (b) above are met, the GM 
may release the card after successfully completing the updating of account records or information, 
or both). 
10.15 Player input 
10.15.1 The player's selected input shall be interpreted correctly and acted upon in accordance 
with the description of the choice as indicated on the labelling artwork or display. 
10.15.2 A GD shall not be affected by the simultaneous or sequential activation of the various 
inputs. 
10.15.3 In regard to multiline games, each additional line that is brought into play by the wagering 
of a further credit or credits shall be clearly so indicated by the game that the player is in no doubt 
as to which lines are in play. 
10.15.4 In the case of multiline games, the winning play line(s) shall be clearly highlighted to the 
player. This may be accomplished by drawing a line over the symbols on the play line(s) or by 
flashing of winning symbols and line selection box (or both). Where there are wins on multiple 
lines, alternative indication (for example alternate flashing of winning patterns) may be given. 
10.16 Jackpot controllers and displays 
10.16.1 General requirements 
Jackpots or progressive jackpots shall comply with the following: 
a) the winning of the jackpot or progressive jackpot shall be determined by a GD that participates 
in the jackpot or progressive jackpot, and 
b) the winning of the jackpot or progressive jackpot shall be based upon a random event, and 
c) there shall be an equally likely chance that the winning of the jackpot or progressive jackpot 
may occur at all times for each play of a GD that contributes to the progressive prize, and 
d) there shall be clear indication of which device won the jackpot or progressive jackpot in a back 
to-back hit situation. 
e) if a minimum bet amount exists in order for a player to participate in a linked jackpot, then the 
player shall be notified accordingly.  
NOTE These requirements do not apply to mystery jackpots. 
10.16.2 Handling of faults 
If a jackpot controller or a display device exhibits a fault or if communications are lost for any 
reason, the software shall, where possible, notify the system that monitors the jackpot controller 
about such interruption. This does not apply to stand-alone jackpot controllers.  
When a controller fault occurs, it is preferred that it alternates the displays between the current 
amount and an appropriate fault message (this may not be applicable for purely BCD driven 
displays). DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  liii 
 Provision shall be made for resolving the problem that occurs if the system determines that a 
jackpot has been won, but the link to the jackpot controller becomes inoperable (e.g. offline 
jackpot).  
10.16.3 Display requirements 
10.16.3.1 The jackpot or progressive jackpot value shall be accurate to one (1) cent at the time of 
a win, utilizing the principle of rounding up values greater than or equal to 0,5 and rounding down 
values less that 0,5 to the closest cent in the calculation of the value. 
10.16.3.2 The jackpot or progressive jackpot display shall never exceed the amount accrued. 
10.16.4 Jackpot awards 
10.16.4.1 There shall be a clear visual indication of the winning of a jackpot or progressive jackpot 
on the gaming floor .  
10.16.4.2 The progressive controller shall accommodate the situation where two jackpots are 
awarded "back- to-back" (that is, are awarded before the controller has reset the progressive 
display). 
10.16.4.3 The jackpot system shall provide the GD that triggered the jackpot or progressive 
jackpot with the amount of the jackpot or progressive jackpot won. 
10.16.5 Controller requirements 
10.16.5.1 Jackpot and progressive jackpots shall be monitored and controlled at all times. If the 
jackpot controller is a stand-alone unit, then there shall be a secure facility to access the jackpot 
meter information.  
10.16.5.2 A progressive jackpot may be controlled by any of the following: 
a) the game (progressive); 
b) the progressive jackpot controller; and 
c) the jackpot server.  
10.16.5.3 When a progressive jackpot prize amount reaches a cap or ceiling value, all additional 
contributions shall be credited to a diversion pool that shall prevent such further contributions 
being absorbed into casino revenue.  
NOTE Deleted by amendment No. 2. 
10.16.5.4 Where a "master controller" employs "slave controllers" to control a linked progressive 
jackpot, jackpot hit events shall be time-stamped and the master controller shall ensure that 
a) all slave controllers are time-synchronized, and 
b) the minimum time increment is not less than the total time taken to 
1) register that a jackpot has displayed, 
2) lock up the winning device, and 
3) reset the progressive meter. DUS 1580-1 : 2014 
liv © UNBS 2017  – All rights reserved  
 10.16.6 Security of jackpot parameters 
The method by which system jackpot parameter values are modified or entered shall be secure. 
Parameters to be addressed are: 
a) increment values, 
b) secondary pool increments, 
c) reset values, 
d) maximum values, and 
e) GDs that participate. 
If parameters are changed on a jackpot that is active, the application of these changes shall not 
apply until the jackpot is won other than by a full RAM reset. 
The current jackpot amounts, including overflow meters, shall be able to be set once per RAM 
reset in configuration mode. The default values shall be the reset amounts and game play shall 
not be permitted until the current values are set to a value equal to or greater than the default 
value and accepted (or the default values have been accepted). 
A Mystery Jackpot that uses a hidden jackpot amount to determine the jackpot win shall not 
change the hidden jackpot amount when the parameters are changed if the jackpot is active (i.e. 
had any jackpot contributions added to it).  
 
 DUS 1580-1:2017 
© UNBS 2017  – All rights reserved  lv 
 Certification marking 
Products that conform to Uganda standards may be marked with Uganda National Bureau of 
Standards (UNBS) Certification Mark shown in the figure below.  
The use of the UNBS Certification Mark is governed by the Standards Act, and the Regulations 
made thereunder. This mark can be used only by those licensed under the certification mark 
scheme operated by the Uganda National Bureau of Standards and in conjunction with the 
relevant Uganda Standard. The presence of this mark on a product or in relation to a product is an 
assurance that the goods comply with the requirements of that standard under a system of 
supervision, control and testing in accordance with the certification mark scheme of the Uganda 
National Bureau of Standards. UNBS marked products are continually checked by UNBS for 
conformity to that standard.  
Further particulars of the terms and conditions of licensing may be obtained from the Director, 
Uganda National Bureau of Standards.  
 DUS 1551 : 2017    
 
ICS nn.nnn.nn 
Price based on nn pages 
© UNBS 2017  – All rights reserved