2023-09-03 07:37:54 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 05:30:36 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 04:46:34 +00:00
2023-08-21 10:30:42 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 04:46:34 +00:00
2023-08-21 10:30:42 +00:00
2023-08-26 02:33:13 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 05:30:36 +00:00
2023-08-20 05:54:53 +00:00
2023-09-03 05:30:36 +00:00
2023-09-03 07:37:54 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 07:37:54 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 04:46:34 +00:00
2023-09-03 04:46:34 +00:00

###########
scu-dsp-asm
###########

scu-dsp-asm is an assembler for SCU DSP mnemonics, using SEGA syntax.

Usage:

.. code::

   scu-dsp-asm input-file.asm output-file.bin

Alternately, use the ``-s`` (source code) command-line argument to
emit a C-syntax source code fragment:

.. code::

   scu-dsp-asm -s input-file.asm output-file.inc

If no arguments are given, scu-dsp-asm starts a basic REPL.

Wherever possible, scu-dsp-asm attempts to preserve compatibility with
the same source code used with the SEGA-authored ``dspasm.exe``,
**except** in the cases where ``dspasm.exe`` behavior is considered a
bug.

Current status
==============

100% of the documented dspasm.exe features are supported, as well as
miscellaneous undocumented features.

scu-dsp-asm correctly assembles all of the examples in the test/
directory in this repository, with caveats listed below.

scp-dsp-asm has not been tested exhaustively, and the test programs do
not cover 100% of the possible SCU DSP instructions or arguments.

Differences that affect source code
===================================

M0-M3 must not appear in in DMA source/destination arguments
------------------------------------------------------------

For example, the following are not legal:

.. code::

   DMA D0,M0,#$02
   DMA M1,D0,#$02

Instead, they should be written as:

.. code::

   DMA D0,MC0,#$02
   DMA MC1,D0,#$02

``dspasm.exe`` generates the same code given either the former or
latter example as input. scu-dsp-asm, however, rejects the former
example as invalid: it misleads what the result of the operation is.

This change is not consistent with what is written in the SCU manual
(ST-97-R5-072694).

Differences that affect code generation
=======================================

Spurious invalid X-bus opcode generation
----------------------------------------

Under seemingly-random circumstances, ``dspasm.exe`` emits the
undefined X-bus opcode ``001``. Given:

.. code::

   MOV M3,A  MOV 1,PL

The ``dspasm.exe``-generated code is:

.. code::

   00000000100001101101010100000001
           ^
However, the correct code should be:

.. code::

   00000000000001101101010100000001
           ^

This is particularly interesting because the example mnemonics did not
contain any X-bus operation to start with.

Motorola S-record output is not supported
-----------------------------------------

It is suspected that this feature is not useful.

Misleading, contradictory, and completely incorrect documentation
=================================================================

DMA default "add mode"
----------------------

Contrast to what is written in the SCU manual (ST-97-R5-072694), the
default DMA "add mode" for both dspasm.exe and scp-dsp-asm is
``2``. E.g:

- ``DMA`` is a synonym for ``DMA2``

- ``DMAH`` is a synonym for ``DMAH2``

In "Sega Developers Conference Conference Proceedings March 5-7, 1996"
pdf page 48, printed page 3-14, slide 25:

   You need to modify your object code, either by hand or with a
   custom tool.

This is completely incorrect, and both scu-dsp-asm and dspasm.exe will
emit "add mode 1" via the ``DMA1`` and ``DMAH1`` mnemonics.

DMA "add mode" and bytes
------------------------

All of the SEGA-authored documentation on this topic is invalid. The
the correct relationship between DMA "add mode" mnemonics and bus
address offsets is shown below. The right columns represent the
increment added to the bus address after each bus transfer:

.. list-table::
   :header-rows: 1
   :stub-columns: 1

   * - mnemonic
     - D0 → [RAM]
     - [RAM] → D0
   * - DMA0
     - 0 bytes
     - 0 bytes
   * - DMA1
     - 0 bytes
     - 2 bytes
   * - DMA2
     - 4 bytes
     - 4 bytes
   * - DMA4
     - 4 bytes
     - 8 bytes
   * - DMA8
     - 0 bytes
     - 16 bytes
   * - DMA16
     - 0 bytes
     - 32 bytes
   * - DMA32
     - 4 bytes
     - 64 bytes
   * - DMA64
     - 4 bytes
     - 128 bytes

Note that the DMA transfer length is always decremented by 1 after 4 bytes are
transferred, regardless of the size of the bus transfer.

Note that selecting DMA1 on a 4-byte bus does not generate misaligned
writes; instead, the following happens:

.. code:: c

   uint32_t src[] = { 1, 2, 3, 4, ... };
   extern uint32_t dst[];
   
   dst[0] = src[0];
   dst[0] = src[1];
   dst[1] = src[2];
   dst[1] = src[3];
   ...

   // dst = { 2, 2, 4, 4, ... };

The SCU manual (ST-97-R5-072694) contains this contradictory text:

   Only add numbers 0 and 1 are valid for the A-Bus and the write unit is
   32bit. [...] Write unit is 16bit; 32bit data is divided in half and written
   at intervals of 16X (0-64).

"Multiply the 'add number' by the [number of bytes per transfer] **depending on
the value of WA0/RA0**" is completely incorrect. The text in the original
Japanese document is also incorrect.

Syntax features that are supported, but with misleading consequences
====================================================================

``NOP`` mnemonics inside OP instructions
----------------------------------------

In both scu-dsp-asm and ``dspasm.exe``, ALU, X-bus, Y-bus, and D1-bus mnemonics
may appear in any order in a single OP instruction and/or line of source code.

From a grammar perspective, it is impossible to disambiguate which bus a ``NOP``
is referring to. For example, this is valid code:

.. code::

   NOP  NOP  NOP  NOP  MOV MUL,P

Even though it visually might appear that the X-bus operation might be
simultaneously ``NOP`` and ``MOV MUL,P``, due to syntactical ambiguity the
assembler is not able to generate an error for this case.

There is no restriction on the number of ``NOP`` values that can appear on a
single line.

Feel free to use this syntax feature if desired stylistically, but be aware
scu-dsp-asm is not able to verify intent, and does not/can not generate errors
related to a "conflict" between a ``NOP`` mnemonic and any other bus operation.

Immediates with ``:``-suffixes or ``#``-prefixes
------------------------------------------------

In both scu-dsp-asm and ``dspasm.exe``, neither of these characters mean
anything in the grammar. If encountered, they are ignored.

For example, all of the following is valid source code:

.. code::

   MVI #1,MC0
   MVI 1:,MC0
   MVI #foobar,MC0
   MVI #foobar:,MC0
   MVI #1+1:,MC0
   MVI #(1+1):,MC0

Feel free to use these characters if desired stylistically, but be aware that
scu-dsp-asm does not generate errors regardless of how they are used.
Description
No description provided
Readme 609 KiB
Languages
C++ 85.1%
Python 9.3%
Assembly 3.6%
Makefile 1.6%
Shell 0.4%