Skip to content
This repository
Browse code

Merge pull request #40 from DCPUTeam/master

Brought in extension table draft and test suite.
  • Loading branch information...
commit 442e92b28b4f656e2f677f37aa08ad6335bdb9b0 2 parents 61348f2 + dae9b96
James Rhodes authored April 25, 2012
2  ASM/Draft_Assembly_Relocation_Table.txt
... ...
@@ -1,4 +1,4 @@
1  
-RFC X1001 (Draft-Asm)                                     J. Rhodes, Ed.
  1
+RFC X____ (Draft-Asm)                                     J. Rhodes, Ed.
2 2
                                                        Redpoint Software
3 3
                                                               April 2012
4 4
 
4  ASM/Draft_Assembly_Relocation_Table.xml
@@ -8,8 +8,8 @@
8 8
 <?rfc sortrefs="yes" ?>
9 9
 <?rfc compact="yes" ?>
10 10
 <?rfc subcompact="no" ?>
11  
-<?rfc private="RFC X1001 (Draft-Asm)" ?>
12  
-<rfc ipr="none" number="1001" category="info" docName="draft-assembly-relocation-table">
  11
+<?rfc private="RFC X____ (Draft-Asm)" ?>
  12
+<rfc ipr="none" number="____" category="info" docName="draft-assembly-relocation-table">
13 13
   <front>
14 14
     <title abbrev="Assembly Relocation Table">Assembly Relocation Table</title>
15 15
 
332  ASM/Draft_Extension_Declaration_Table.txt
... ...
@@ -0,0 +1,332 @@
  1
+RFC X____ (Draft-Asm)                                     J. Rhodes, Ed.
  2
+                                                       Redpoint Software
  3
+                                                              April 2012
  4
+
  5
+
  6
+                      Extension Declaration Table
  7
+
  8
+Abstract
  9
+
  10
+   This draft provides a formal structure for assemblers to notify
  11
+   emulators what non-standard extensions a specific set of binary code
  12
+   is relying on (such as input or hardware interfaces).
  13
+
  14
+
  15
+Table of Contents
  16
+
  17
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
  18
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 2
  19
+   2.  Extension Definition  . . . . . . . . . . . . . . . . . . . . . 2
  20
+   3.  Role of Assemblers  . . . . . . . . . . . . . . . . . . . . . . 2
  21
+   4.  Role of Emulators . . . . . . . . . . . . . . . . . . . . . . . 3
  22
+   5.  Extension Table Format  . . . . . . . . . . . . . . . . . . . . 3
  23
+   6.  Extension Table Positioning . . . . . . . . . . . . . . . . . . 4
  24
+   7.  Extension Names . . . . . . . . . . . . . . . . . . . . . . . . 5
  25
+     7.1.  experimental-output-screen-32x12-0x8000 . . . . . . . . . . 5
  26
+     7.2.  experimental-output-screen-32x16-0x8000 . . . . . . . . . . 5
  27
+     7.3.  experimental-input-keyboard-single-0x9000 . . . . . . . . . 5
  28
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
  29
+   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
  30
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
  31
+
  32
+
  33
+
  34
+
  35
+
  36
+
  37
+
  38
+
  39
+
  40
+
  41
+
  42
+
  43
+
  44
+
  45
+
  46
+
  47
+
  48
+
  49
+
  50
+
  51
+
  52
+Rhodes                                                          [Page 1]
  53
+
  54
+                       Extension Declaration Table            April 2012
  55
+
  56
+
  57
+1.  Introduction
  58
+
  59
+   There are currently a wide variety of implementations for hardware
  60
+   components such as screens and keyboard input.  Each implementation
  61
+   of this hardware varies between emulator causing unintended
  62
+   discrepancies when running assembly code in a different emulator.
  63
+
  64
+   This RFC strives to ensure that emulators provide only standard
  65
+   functionality unless experimental features are explicitly requested
  66
+   when assembling the code originally.
  67
+
  68
+1.1.  Requirements Language
  69
+
  70
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  71
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  72
+   document are to be interpreted as described in RFC 2119 [RFC2119].
  73
+
  74
+
  75
+2.  Extension Definition
  76
+
  77
+   An extension is herein defined as a request for additional
  78
+   functionality to be provided by the emulator or assembler which is
  79
+   not yet an approved standard.
  80
+
  81
+   This includes functionality which is widely used in the community
  82
+   (screens and keyboard input at the time of writing) that has not yet
  83
+   been confirmed by Notch.
  84
+
  85
+
  86
+3.  Role of Assemblers
  87
+
  88
+   For the purposes of this draft, the role of assemblers is to generate
  89
+   code from a defined syntax to DCPU-16 bytecode.
  90
+
  91
+   In this case, assemblers MUST generate an extension table, unless the
  92
+   total number of extensions requested is 0, in which case the
  93
+   assembler MUST NOT generate an extension table.
  94
+
  95
+   Assemblers SHOULD support a directive format that allows users to
  96
+   specify which extensions they wish to use, although the exact syntax
  97
+   of the format is not specified.  If an assembler provides syntax to
  98
+   the user to enable a given extension, they MUST use the extension
  99
+   names specified in this document.  If an assembler does not provide a
  100
+   syntax to enable specific extensions, it MUST NOT emit an extension
  101
+   table under any circumstances.  From herein, the syntax through which
  102
+   an assembler allows extensions to be enabled will be referred to as
  103
+   the 'extension directive'.
  104
+
  105
+
  106
+
  107
+
  108
+Rhodes                                                          [Page 2]
  109
+
  110
+                       Extension Declaration Table            April 2012
  111
+
  112
+
  113
+   When functionality that was previously provided via an extension
  114
+   becomes standardized, assemblers that have support for recognising
  115
+   the specific extension SHOULD continue to recognise it in the
  116
+   extension directive for a reasonable period, after which they MAY
  117
+   drop recognising it (for example, at a next major release).
  118
+
  119
+   If an assembler did not previously recognise a specific extension
  120
+   name, and the extension becomes standardized, then the assembler
  121
+   SHOULD NOT recognise the extension name in the extension directive,
  122
+   unless it is still widely used.
  123
+
  124
+
  125
+4.  Role of Emulators
  126
+
  127
+   For the purposes of this draft, the role of emulators is to execute
  128
+   DCPU-16 bytecode produced by an assembler according to standards laid
  129
+   out officially by Notch and the committee.
  130
+
  131
+   If an emulator is executing bytecode which does not have an extension
  132
+   table in the specified format, it MUST NOT provide any additional
  133
+   features other than those defined in standards.
  134
+
  135
+   Emulators MUST NOT provide non-standard functionality unless it is
  136
+   specifically requested by the code.  This includes current non-
  137
+   standard extensions such as screens and keyboard input; emulators
  138
+   MUST stop providing this functionality to code that does not request
  139
+   it.  [The author of this draft is aware that this will prevent
  140
+   existing compiled code from working in standardized emulators; this
  141
+   is intended to ensure code standardization]
  142
+
  143
+   Emulators MAY drop support or add support for extensions at any time,
  144
+   without any prerequisites on doing so.
  145
+
  146
+   Unlike assemblers, when functionality that was previously provided
  147
+   via an extension becomes standardized, emulators MUST continue to
  148
+   support the extension in the extension table.
  149
+
  150
+   In addition, when functionality that was previously provided via an
  151
+   extension that the emulator did not support becomes standardized,
  152
+   emulators MUST support the new standard and MUST recognise the
  153
+   previously used extension name (although it will not affect emulator
  154
+   functionality as the extension functionality is now standard).
  155
+
  156
+
  157
+5.  Extension Table Format
  158
+
  159
+   For purposes of future versioning, this document specifies version 1
  160
+   of the extension table format.
  161
+
  162
+
  163
+
  164
+Rhodes                                                          [Page 3]
  165
+
  166
+                       Extension Declaration Table            April 2012
  167
+
  168
+
  169
+   The format of the extension table is as follows:
  170
+
  171
+            +----------------------------+-------------------+
  172
+            |            Field           |        Size       |
  173
+            +----------------------------+-------------------+
  174
+            |    Magic number (0xF100)   |    Single word    |
  175
+            |   Version number (0x0001)  |    Single word    |
  176
+            | Number of entries in table |    Single word    |
  177
+            |           Entry 1          | String length + 1 |
  178
+            |             ...            |        ...        |
  179
+            |           Entry N          | String length + 1 |
  180
+            +----------------------------+-------------------+
  181
+
  182
+                         Table 1: Extension Table
  183
+
  184
+   Each string is a unique entry, and one either defined in the table
  185
+   below, or may be a non-standard name (providing it is unique and
  186
+   meaningful) that is defined by either an assembler or emulator.
  187
+
  188
+   Strings are formatted with each ASCII character taking up a single
  189
+   word, plus a NULL terminator (which also takes up a single word).
  190
+   Thus the size of a string is the number of characters, plus one for
  191
+   the terminator (as shown in the table above).
  192
+
  193
+   Note that the "Number of entries" is strictly this; the table does
  194
+   not expose it's total size in words.
  195
+
  196
+
  197
+6.  Extension Table Positioning
  198
+
  199
+   The assembly extension table must be positioned inside the generated
  200
+   code, but have no effect on the program execution.
  201
+
  202
+   When an assembler generates an extension table, the first instruction
  203
+   MUST be a jump to the start of the actual program code.  This results
  204
+   in the first two words being:
  205
+
  206
+                 +---------------------------------------+
  207
+                 |        Contents of single Word        |
  208
+                 +---------------------------------------+
  209
+                 |     SET PC, <next word literally>     |
  210
+                 | Location of first program instruction |
  211
+                 +---------------------------------------+
  212
+
  213
+                      Table 2: Extension Setup Table
  214
+
  215
+   It is important to note that assemblers will have to offset all label
  216
+   addresses by the total size (not number of entries) of the extension
  217
+
  218
+
  219
+
  220
+Rhodes                                                          [Page 4]
  221
+
  222
+                       Extension Declaration Table            April 2012
  223
+
  224
+
  225
+   table, plus the two words at the start.
  226
+
  227
+
  228
+7.  Extension Names
  229
+
  230
+   The following is a list of extension names currently applicable.
  231
+   Assemblers and emulators SHOULD support these directives until such
  232
+   time as the specific functionality is standardized.
  233
+
  234
+               +-------------------------------------------+
  235
+               |                    Name                   |
  236
+               +-------------------------------------------+
  237
+               |  experimental-output-screen-32x12-0x8000  |
  238
+               |  experimental-output-screen-32x16-0x8000  |
  239
+               | experimental-input-keyboard-single-0x9000 |
  240
+               +-------------------------------------------+
  241
+
  242
+                         Table 3: Extension Names
  243
+
  244
+   Individual assemblers and emulators may support names outside these
  245
+   values.  If an emulator encounters an extension name that it can not
  246
+   handle, it MUST NOT execute the byte code.
  247
+
  248
+   Likewise, if an assembler encounters an extension name that it does
  249
+   not recognise, it MUST NOT assemble the byte code and MUST inform the
  250
+   user that it does not support the extension name.
  251
+
  252
+7.1.  experimental-output-screen-32x12-0x8000
  253
+
  254
+   Indiciates that the code wishes for a memory-mapped screen to be
  255
+   positioned at 0x8000 in RAM, with a size of 32x12.
  256
+
  257
+7.2.  experimental-output-screen-32x16-0x8000
  258
+
  259
+   Indiciates that the code wishes for a memory-mapped screen to be
  260
+   positioned at 0x8000 in RAM, with a size of 32x16.
  261
+
  262
+7.3.  experimental-input-keyboard-single-0x9000
  263
+
  264
+   Indiciates that the code wishes for the ASCII code of the last key
  265
+   pressed to be placed at 0x9000.  The emulator only exposes the
  266
+   single, last key pressed and MUST NOT clear the position when the key
  267
+   is released.  The emulator MUST continue to set the value of 0x9000
  268
+   whileever a key is held down.
  269
+
  270
+
  271
+
  272
+
  273
+
  274
+
  275
+
  276
+Rhodes                                                          [Page 5]
  277
+
  278
+                       Extension Declaration Table            April 2012
  279
+
  280
+
  281
+8.  Security Considerations
  282
+
  283
+   The extension table is read once at the start by an emulator and
  284
+   hence even if the program overwrites it's own extension table, it has
  285
+   no effect on on-going execution.
  286
+
  287
+   Emulators MUST NOT enable features if the extension table changes at
  288
+   run-time.
  289
+
  290
+
  291
+9.  Normative References
  292
+
  293
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
  294
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
  295
+
  296
+
  297
+Author's Address
  298
+
  299
+   James Rhodes (editor)
  300
+   Redpoint Software
  301
+
  302
+   Email: jrhodes@redpointsoftware.com.au
  303
+   URI:   http://www.redpointsoftware.com.au/
  304
+
  305
+
  306
+
  307
+
  308
+
  309
+
  310
+
  311
+
  312
+
  313
+
  314
+
  315
+
  316
+
  317
+
  318
+
  319
+
  320
+
  321
+
  322
+
  323
+
  324
+
  325
+
  326
+
  327
+
  328
+
  329
+
  330
+
  331
+
  332
+Rhodes                                                          [Page 6]
215  ASM/Draft_Extension_Declaration_Table.xml
... ...
@@ -0,0 +1,215 @@
  1
+<?xml version="1.0" encoding="US-ASCII"?>
  2
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
  3
+<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  4
+<?rfc strict="yes" ?>
  5
+<?rfc toc="yes"?>
  6
+<?rfc tocdepth="4"?>
  7
+<?rfc symrefs="yes"?>
  8
+<?rfc sortrefs="yes" ?>
  9
+<?rfc compact="yes" ?>
  10
+<?rfc subcompact="no" ?>
  11
+<?rfc private="RFC X____ (Draft-Asm)" ?>
  12
+<rfc ipr="none" number="____" category="info" docName="draft-assembly-relocation-table">
  13
+  <front>
  14
+    <title abbrev="Extension Declaration Table">Extension Declaration Table</title>
  15
+
  16
+    <author fullname="James Rhodes" initials="J.R." role="editor"
  17
+            surname="Rhodes">
  18
+      <organization>Redpoint Software</organization>
  19
+
  20
+      <address>
  21
+        <email>jrhodes@redpointsoftware.com.au</email>
  22
+        <uri>http://www.redpointsoftware.com.au/</uri>
  23
+      </address>
  24
+    </author>
  25
+
  26
+    <date month="April" year="2012" />
  27
+    <area>Asm</area>
  28
+    <workgroup>0x10c Standards Committee</workgroup>
  29
+    <abstract>
  30
+      <t>This draft provides a formal structure for assemblers to notify
  31
+      emulators what non-standard extensions a specific set of binary
  32
+      code is relying on (such as input or hardware interfaces).</t>
  33
+    </abstract>
  34
+  </front>
  35
+
  36
+  <middle>
  37
+    <section title="Introduction">
  38
+      <t>There are currently a wide variety of implementations for hardware
  39
+      components such as screens and keyboard input.  Each implementation
  40
+      of this hardware varies between emulator causing unintended discrepancies
  41
+      when running assembly code in a different emulator.</t>
  42
+      <t>This RFC strives
  43
+      to ensure that emulators provide only standard functionality unless
  44
+      experimental features are explicitly requested when assembling the code
  45
+      originally.</t>
  46
+
  47
+      <section title="Requirements Language">
  48
+        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  49
+        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  50
+        document are to be interpreted as described in <xref
  51
+        target="RFC2119">RFC 2119</xref>.</t>
  52
+      </section>
  53
+    </section>
  54
+    
  55
+    <section anchor="extension-definition" title="Extension Definition">
  56
+      <t>An extension is herein defined as a request for additional functionality
  57
+      to be provided by the emulator or assembler which is not yet an approved
  58
+      standard.</t>
  59
+      <t>This includes functionality which is widely used in the
  60
+      community (screens and keyboard input at the time of writing) that has
  61
+      not yet been confirmed by Notch.</t>
  62
+    </section>
  63
+    
  64
+    <section anchor="role-of-assemblers" title="Role of Assemblers">
  65
+      <t>For the purposes of this draft, the role of assemblers is to generate
  66
+      code from a defined syntax to DCPU-16 bytecode.</t>
  67
+      <t>In this case, assemblers MUST generate an extension table, unless
  68
+      the total number of extensions requested is 0, in which case the
  69
+      assembler MUST NOT generate an extension table.</t>
  70
+      <t>Assemblers SHOULD support a directive format that allows users to
  71
+      specify which extensions they wish to use, although the exact syntax
  72
+      of the format is not specified.  If an assembler provides syntax to
  73
+      the user to enable a given extension, they MUST use the extension
  74
+      names specified in this document.  If an assembler does not provide
  75
+      a syntax to enable specific extensions, it MUST NOT emit an extension
  76
+      table under any circumstances.  From herein, the syntax through which
  77
+      an assembler allows extensions to be enabled will be referred to as
  78
+      the 'extension directive'.</t>
  79
+      <t>When functionality that was previously provided via an extension
  80
+      becomes standardized, assemblers that have support for recognising the specific
  81
+      extension SHOULD continue to recognise it in the extension directive
  82
+      for a reasonable period, after which they MAY drop recognising it
  83
+      (for example, at a next major release).</t>
  84
+      <t>If an assembler did not previously recognise a specific
  85
+      extension name, and the extension becomes standardized, then the
  86
+      assembler SHOULD NOT recognise the extension name in the extension
  87
+      directive, unless it is still widely used.</t>
  88
+    </section>
  89
+    
  90
+    <section anchor="role-of-emulators" title="Role of Emulators">
  91
+      <t>For the purposes of this draft, the role of emulators is to execute
  92
+      DCPU-16 bytecode produced by an assembler according to standards laid
  93
+      out officially by Notch and the committee.</t>
  94
+      <t>If an emulator is executing bytecode which does not have an extension
  95
+      table in the specified format, it MUST NOT provide any additional features
  96
+      other than those defined in standards.</t>
  97
+      <t>Emulators MUST NOT provide non-standard functionality unless it is
  98
+      specifically requested by the code.  This includes current non-standard
  99
+      extensions such as screens and keyboard input; emulators MUST stop providing
  100
+      this functionality to code that does not request it.  [The author of this
  101
+      draft is aware that this will prevent existing compiled code from working
  102
+      in standardized emulators; this is intended to ensure code standardization]</t>
  103
+      <t>Emulators MAY drop support or add support for extensions at any time,
  104
+      without any prerequisites on doing so.</t>
  105
+      <t>Unlike assemblers, when functionality that was previously provided
  106
+      via an extension becomes standardized, emulators MUST continue to support
  107
+      the extension in the extension table.</t>
  108
+      <t>In addition, when functionality that was previously provided via
  109
+      an extension that the emulator did not support becomes standardized,
  110
+      emulators MUST support the new standard and MUST recognise the previously
  111
+      used extension name (although it will not affect emulator functionality
  112
+      as the extension functionality is now standard).</t>
  113
+    </section>
  114
+    
  115
+    <section anchor="extension-table-format" title="Extension Table Format">
  116
+      <t>For purposes of future versioning, this document specifies version 1
  117
+         of the extension table format.</t>
  118
+      <t>The format of the extension table is as follows:</t>
  119
+      <texttable anchor="extension-table" title="Extension Table">
  120
+        <ttcol align="center">Field</ttcol>
  121
+        <ttcol align="center">Size</ttcol>
  122
+        <c>Magic number (0xF100)</c>
  123
+        <c>Single word</c>
  124
+        <c>Version number (0x0001)</c>
  125
+        <c>Single word</c>
  126
+        <c>Number of entries in table</c>
  127
+        <c>Single word</c>
  128
+        <c>Entry 1</c>
  129
+        <c>String length + 1</c>
  130
+        <c>...</c>
  131
+        <c>...</c>
  132
+        <c>Entry N</c>
  133
+        <c>String length + 1</c>
  134
+      </texttable>
  135
+      <t>Each string is a unique entry, and one either defined in the
  136
+      table below, or may be a non-standard name (providing it is
  137
+      unique and meaningful) that is defined by either an assembler
  138
+      or emulator.</t>
  139
+      <t>Strings are formatted with each ASCII character taking up a
  140
+      single word, plus a NULL terminator (which also takes up a single
  141
+      word).  Thus the size of a string is the number of characters,
  142
+      plus one for the terminator (as shown in the table above).</t>
  143
+      <t>Note that the "Number of entries" is strictly this; the table
  144
+      does not expose it's total size in words.</t>
  145
+    </section>
  146
+
  147
+    <section anchor="extension-table-position" title="Extension Table Positioning">
  148
+      <t>The assembly extension table must be positioned inside the generated
  149
+      code, but have no effect on the program execution.</t>
  150
+      <t>When an assembler generates an extension table, the first instruction
  151
+      MUST be a jump to the start of the actual program code.  This results
  152
+      in the first two words being:</t>
  153
+      <texttable anchor="extension-setup-table" title="Extension Setup Table">
  154
+        <ttcol align="center">Contents of single Word</ttcol>
  155
+        <c>SET PC, &lt;next word literally&gt;</c>
  156
+        <c>Location of first program instruction</c>
  157
+      </texttable>
  158
+      <t>It is important to note that assemblers will have to offset all label
  159
+      addresses by the total size (not number of entries) of the extension
  160
+      table, plus the two words at the start.</t>
  161
+    </section>
  162
+    
  163
+    <section anchor="extension-names" title="Extension Names">
  164
+      <t>The following is a list of extension names currently applicable.
  165
+      Assemblers and emulators SHOULD support these directives until such
  166
+      time as the specific functionality is standardized.</t>
  167
+      <texttable anchor="extension-names-table" title="Extension Names">
  168
+        <ttcol align="center">Name</ttcol>
  169
+        <c>experimental-output-screen-32x12-0x8000</c>
  170
+        <c>experimental-output-screen-32x16-0x8000</c>
  171
+        <c>experimental-input-keyboard-single-0x9000</c>
  172
+      </texttable>
  173
+      <t>Individual assemblers and emulators may support names outside
  174
+      these values.  If an emulator encounters an extension name that
  175
+      it can not handle, it MUST NOT execute the byte code.</t>
  176
+      <t>Likewise, if an assembler encounters an extension name that it does not
  177
+      recognise, it MUST NOT assemble the byte code and MUST inform
  178
+      the user that it does not support the extension name.</t>
  179
+
  180
+      <section title="experimental-output-screen-32x12-0x8000">
  181
+        <t>Indiciates that the code wishes for a memory-mapped screen to
  182
+        be positioned at 0x8000 in RAM, with a size of 32x12.</t>
  183
+      </section>
  184
+      
  185
+      <section title="experimental-output-screen-32x16-0x8000">
  186
+        <t>Indiciates that the code wishes for a memory-mapped screen to
  187
+        be positioned at 0x8000 in RAM, with a size of 32x16.</t>
  188
+      </section>
  189
+      
  190
+      <section title="experimental-input-keyboard-single-0x9000">
  191
+        <t>Indiciates that the code wishes for the ASCII code of the last
  192
+        key pressed to be placed at 0x9000.  The emulator only exposes the single,
  193
+        last key pressed and MUST NOT clear the position when the key
  194
+        is released.  The emulator MUST continue to set the value of
  195
+        0x9000 whileever a key is held down.</t>
  196
+      </section>
  197
+    </section>
  198
+    
  199
+    <section anchor="security" title="Security Considerations">
  200
+      <t>The extension table is read once at the start by an emulator and hence
  201
+      even if the program overwrites it's own extension table, it has no effect
  202
+      on on-going execution.</t>
  203
+      <t>Emulators MUST NOT enable features if the extension table changes
  204
+      at run-time.</t>
  205
+    </section>
  206
+  </middle>
  207
+
  208
+  <back>
  209
+    <references title="Normative References">
  210
+      <?rfc include="reference.RFC.2119.xml"?>
  211
+    </references>
  212
+  </back>
  213
+
  214
+</rfc>
  215
+
6  README.md
Source Rendered
@@ -19,9 +19,15 @@ In here go all specifications and proposals for the layout and implementation of
19 19
 ### NET ###
20 20
 Anything about networking goes in the net folder.
21 21
 
  22
+### HW ###
  23
+Anything about hardware components and communicating directly with hardware components goes in here.
  24
+
22 25
 ### MISC ###
23 26
 In this directory goes everything that does not fit in the other directories defined above.
24 27
 
  28
+### TESTS ###
  29
+Tests for software that can be used to ensure standards compliance.
  30
+
25 31
 
26 32
 ## Procedures and Naming Standards ##
27 33
 
33  TESTS/high-nerd.dasm16
... ...
@@ -0,0 +1,33 @@
  1
+;
  2
+; Unit test by James Rhodes
  3
+;
  4
+; This unit test ensures emulator compliance with how high-nerd
  5
+; should work.  Corrections and expansions are appreciated.
  6
+;
  7
+
  8
+;
  9
+; At the end of the test, the emulator state should be (empty
  10
+; indicates the value is unspecified):
  11
+;
  12
+;   A:   0x0000              [A]:   
  13
+;   B:   0x0000              [B]:   
  14
+;   C:   0xFB50              [C]:   
  15
+;   X:   0x0000              [X]:   
  16
+;   Y:   0x0000              [Y]:   
  17
+;   Z:   0x0000              [Z]:   
  18
+;   I:   0x0000              [I]:   
  19
+;   J:   0x0000              [J]:   
  20
+;   PC:                      SP:    0x0000
  21
+;   EX:  0x5556              IA:    0x0000
  22
+;
  23
+
  24
+SET C, 500      ; C = 500
  25
+ADD C, 499      ; C = 999
  26
+SUB C, 99       ; C = 900
  27
+MUL C, 2        ; C = 1800
  28
+SET A, 0xFFFF   ; C = 1800, A = 0xFFFF
  29
+SUB A, C        ; C = 1800, A = 0xF8F8
  30
+SET C, A        ; C = -1800, A = 0xF8F8
  31
+SET A, 0        ; C = -1800
  32
+MLI C, 2        ; C = -3600
  33
+DVI C, 3        ; C = -1200 (0xFB50)

0 notes on commit 442e92b

Please sign in to comment.
Something went wrong with that request. Please try again.