Describe the bug When using direct addressing mode, no bytes seem to be created. I am using ADCA as an example, but the issue seems to affect all direct addressing mode mnemonics.

To Reproduce Steps to reproduce the behavior:

1. Create a file and call it test.asm:

        ORG    $1000
        ADCA    <$9F

2. Compile using: python assembler.py --print test.asm

Expected behavior With the print parameter in place, it should produce this output:

-- Assembled Statements --
$1000                         ORG $1000                          ;                                         
$1000      999F               ADCA <$9F     

Actual behavior I am getting no byte codes at all:

-- Assembled Statements --
$1000                         ORG $1000                          ;                                         
$1000                         ADCA <$9F     

Describe the bug 16-bit instructions using program counter relative addressing should use 16-bit offsets by default. Currently only LEAX, LEAY, LEAS and LEAU use the correct behavior. Program counter indexed relative addressing modes for instructions STX, STU, STD, ADDD, CMPX, LDD, LDX, LDU, SUBD, CMPD, CMPS, CMPU, LDS, CMPY, LDY, STS, and STY need to be fixed.

To Reproduce

1. Create a file called test.asm and add the following contents:

                ORG     $3F00
START           STX     1,PCR
                LDA     #$0A
NEXT            RTS
                END     START

2. Assemble the file with:

python3 assembler.py test.asm --print

3. Output will be:

-- Assembled Statements --
$3F00                         ORG $3F00                          ;            
$3F00 AF8C01          START   STX 1,PCR                          ;          
$3F03 860A                    LDA #$0A                           ;   
$3F05 39               NEXT   RTS                                ;       
$3F06                         END START                          ;

Expected behavior Correct output should be:

-- Assembled Statements --
$3F00                         ORG $3F00                          ;      
$3F00 AF8D0001        START   STX 1,PCR                          ;                  
$3F04 860A                    LDA #$0A                           ;              
$3F06 39               NEXT   RTS                                ;                
$3F07                         END START                          ;  

Desktop (please complete the following information):

• OS: Ubuntu 20.04
• Python Version: 3.8.10

This PR updates the DiskFile class to have an attribute called granule_fill_order. This list-like object is exactly 68 elements long. Each entry in the list specifies the granule number that should be checked to see if it is empty. The order of the list reflects which granules are allocated first. In DiskConstants there is a constant called GRANULE_FILL_ORDER that mimics the way Disk BASIC attempts to allocate granules on the disk. In general, Disk BASIC attempts to fill granules near the center of the disk first to minimize head stepping. This same ordering is implemented within this PR. The class can be instantiated with a different ordering list, allowing for future customization when generating disk images. Unit tests updated to cover new conditions. This PR closes #73

This PR adds the ability to define multiple single byte declarations using a single FCB statement. Previously, all FCB statements only accepted a single byte definition. For example, to define 3 constant bytes, you would have to:

FCB $55
FCB $44
FCB 17

Now, FCB statements allow for multiple declarations per line, separated with a comma. The following would be equivalent to the code above:

FCB $55,$44,17

Unit and integration tests were added to catch new conditions. README.md documentation was updated to reference multi-byte functionality. This PR closes #53

A feature of Disk Extended Color Basic (DECB) is that it prefers to use granules that are closer to the file allocation table and directory entries (track 17) before using granules that are closer to the outer edges of the disk. This makes sense, since it means stepping the read/write head less frequently after reading the file system data. Currently, the assembler will do a search for free granules starting at granule 0 (the first track). While this isn't an issue when using virtual files, on real media, there may be a noticeable delay when loading data from disk, since the read/write head needs to step a lot in order to read the granule data. The purpose of this feature request is to enable the same behavior in the assembler for populating granules that is seen when using DECB.

This PR restructures the DiskFile class to work with the new VirtualFile structure. While not included in any issues that were open at the time of the PR, this change allows at least disk information to be read and extracted from DSK virtual disks. Unit tests were added to cover a portion of the class. Note that errors may still exist, specifically when looking at files that do not have any preamble or postamble data (e.g. BASIC files).

This PR adds several new unit tests to cover various aspects of the code base that do not have proper unit tests. Significantly, this PR refactors many error handling routines, and pushes them up to outer classes to handle more cleanly. This PR also separates out I/O functions from the assembly routines, so that only data buffers are passed from object to object (this makes for simpler unit testing). Additionally, VirtualFile classes were overhauled, with a new VirtualFileContainer class introduced to distinguish between various container types such as cassette images, disk images, hard disk images, etc. Unit tests are still missing on source_file.py and virtual_file.py as the issue #6 will involve further modification of those files to implement virtual disk access and manipulation. This PR closes #69

This PR simplifies the handling of indexed statements that contain expressions in them. Originally, the code path created a mess of if statements to tackle whether an indexed expression occurred, and also had an expression on the left hand side. The result was an inconsistency into how those statements were handled as opposed to statements that had only a symbol in the left hand side. For example:

STX ADDR,PCR

is handled with different logic than:

STX ADDR+1,PCR

This created a bit of a debugging problem when it came time to reconcile the two code paths. This PR simplifies the handling of such statements by adding a single conditional statement. Additionally, the handling of negative values was pushed entirely to the NumericValue class, so that awkward statements such as jump_distance = 0x100 - jump amount to handle negative numbers didn't get scattered throughout the code base. A few unit tests were updated to catch these new conditions.

This PR closes issue #60 . Specifically, it fixes an issue whereby negative numbers were translated into their absolute value, resulting in positive value outputs instead of negative ones. Unit tests added to cover condition.

Describe the bug Immediate negative integer values not translated correctly.

To Reproduce Steps to reproduce the behavior:

1. Create a file called test.asm.
2. Add the following lines to the test file:

            ORG  $0E00
    START   CMPB #-2
            END  START

4. Run the assembler on the test file as follows:

   python3 assembler.py --print test.asm

5. Output will be as follows:

-- Assembled Statements --
$0E00                         ORG $0E00                          ;                                         
$0E00 C102            START  CMPB #-2                            ;                                         
$0E02                         END START                          ;

Expected behavior The compiled statement for the CMPB #-2 should not be C1 02. The value 02 should be negative, so FE. The output below should be correct:

-- Assembled Statements --
$0E00                         ORG $0E00                          ;                                         
$0E00 C1FE            START  CMPB #-2                            ;                                         
$0E02                         END START                          ;

Desktop (please complete the following information):

• OS: Ubuntu
• Version: 20.04.4
• Python Version: 3.8.10

This PR fixes an error with the following types of statements:

LDA  B,X

The symbol B for accumulator B was not being resolved correctly, and would result in a stacktrace of:

AttributeError: 'str' object has no attribute 'is_address_expression'

Registers can now be specified in the left hand side of indexed expressions correctly. Unit tests added to catch condition.

Implement the ANDR 6309 instruction mnemonic in the assembler. Performs a logical AND with a source and destination register, storing the result in the destination register.

Immediate - $1034, 4 bytes

Register codes:

D - 0000 X - 0001 Y - 0010 U - 0011 S - 0100 PC - 0101 W - 0110 V - 0111 A - 1000 B - 1001 CC - 1010 DP - 1011 E - 1110 F - 1111

Example:

ANDR A,B

Implement the ANDD 6309 instruction mnemonic in the assembler. Performs a logical AND with a double-byte and register D, storing in D.

Immediate - $1084, 4 bytes Direct - $1094, 3 bytes Indexed - $10A4, 3+ bytes Extended - $10B4, 4 bytes

Example:

ANDD #$1010

Currently, the assembler prints out lines that are greater than 120 characters wide when using the --print or --symbols switches. Historically, console windows have been limited to 80 or 100 characters wide when initialized, unless users specify an override. In order for the output of the assembler to be more readable, the output width should be truncated to a reasonable size - approximately 100 or 120 characters. Additionally, a switch should allow for users to specify how wide they want the output to be when printing to the screen.

Add the AIM instruction. Performs a logical AND of an 8-bit immediate value with the contents of a memory byte and stores it in the designated memory byte. Meant to collapse the LDA, ANDA, and STA 6809 operations to perform the same task.

AIM: Direct - $02, 3 bytes Indexed - $62, 3+ bytes Extended - $72, 4 bytes

The command works with the following syntax:

AIM #$0E;$FFFE

Note the semi-colon used to separate the immediate value and the memory address.

In certain circumstances, a user may issue an instruction such as:

LBCC FUNCTION

This instructs the CPU to perform a long branch to where FUNCTION is located in memory. Long branches are useful since they can be used to branch to anywhere in the 64K memory space. However, if FUNCTION is within +129 bytes or -126 bytes of the current instruction, then we can transform the LBCC to a BCC instead, saving several op-cycles, as well as a byte in instruction op-codes.

Implement the ADDR 6309 instruction mnemonic in the assembler. Adds contents of a source register to the contents of the destination register. All registers except for Q and MD are allowed.

Immediate - $1030, 3 bytes

The command works with the following syntax:

ADDR r0,r1

Where r0 is the source and r1 is the destination. The source is stored as the high nibble of the operand byte, and the destination is stored as the low nibble of the operand byte. Valid source and destination values are:

0000 - D 0001 - X 0010 - Y 0011 - U 0100 - S 0101 - PC 0110 - W 0111 - V 1000 - A 1001 - B 1010 - CC 1011 - DP 1110 - E 1111 - F

Example:

$10 30 8E     ADDR A,E