6502.org

Posted: **Sun Nov 22, 2020 8:04 pm**

Edited - this first version has been updated to v1.3.1. See further down this thread for the updated file.

So, here is the first version of the Kowalski Simulator that includes 65816 assembler support. The debugger is disabled when in 65816 mode. Reminder that the code space is still limited to Bank $00 (64k). The assembler should properly assemble code with bank addressing to higher banks, it just cannot store code there yet.

Also, I found a formatting error in the previous V1.2.15 help file for the .OPT command. I fixed that and reuploaded the new file in my previous post. I will include it here also.

Please give the 65816 assembler a try and let me know if you run into any issues. I am including a sample source file that has all the 65816 opcodes with all if its addressing modes used. Use it for reference if you are unsure of the syntax.

Daryl

Posted: **Sun Nov 22, 2020 9:43 pm**

8BIT wrote:

So, here is the first version of the Kowalski Simulator that includes 65816 assembler support. The debugger is disabled when in 65816 mode. Reminder that the code space is still limited to Bank $00 (64k). The assembler should properly assemble code with bank addressing to higher banks, it just cannot store code there yet...Please give the 65816 assembler a try and let me know if you run into any issues. I am including a sample source file that has all the 65816 opcodes with all if its addressing modes used. Use it for reference if you are unsure of the syntax.

I will give 'er a try later this evening. Did you change the radix for bitwise values or is it still @?

Posted: **Mon Nov 23, 2020 1:19 am**

The default is still @, but just add

Code: Select all

     .opt   SwapBin

to your source and it will be reversed.

Daryl

Posted: **Mon Nov 23, 2020 4:38 am**

So, I started converting my SBC-3 DiskOS code and have found an issue that I need to address. It has to do with overriding the detected parameter size. This happens when you want an absolute long addressing mode but the address happens to be in bank 0. My code ran in bank 2 but was referencing IO in bank 0 using absolute long addressing. The macro's that I had written for TASS provided the override.

Kowalski will evaluate the address as a 16 bit value vs 24 bit, and assign absolute address mode vs absolute long.

I know I've seen some discussion on this in the past. I'll dig those up and try to come up with a recommended approach.

Daryl

Posted: **Mon Nov 23, 2020 9:57 am**

Some things I noted during testing:

The problem with the source code editor not recognizing previous settings is back. I seem to recall it has to do with a registry setting.

There doesn't seem to be an unambiguous way to tell the assembler to assemble an immediate mode operand as 16 bits when the MSB is $00. For example:

Code: Select all

00001  1000                	*=$1000
00002  
00003    005A              byte     = $5a
00004    1234              word     = $1234
00005    7890              imm      = $7890
00006    CDEF              long     = $abcdef
00007  
00008  1000  C2 20                  rep #%00100000        ;16-bit accumulator
00009  1002  A9 23 01               lda #$0123            ;assembles w/16-bit operand
00010  1005  A9 23                  lda #$0023            ;assembles w/8-bit operand, should also be 16-bit
00011  
00012  	.END

In the WDC assembler there is are pseudo-ops to deal with that, but I think that method is ill-advised. Better would be an operator to tell the assembler to promote an operand less than $0100 to 16-bits. In my Supermon 816 program I use !#<operand> to force a 16-bit assembly when the MSB is $00.

Regarding jump instructions, I decided in Supermon 816 to implement the following to avoid ambiguity:
Code: Select all
```
4C 34 12     JMP $1234       ;absolute
5C 34 12 AB  JML $AB1234     ;absolute long; JML forces the assembly of a 24-bit operand
6C 34 12     JMP ($1234)     ;absolute indirect
7C 34 12     JMP ($1234,X)   ;absolute indexed indirect
DC 34 12     JMP [$1234]     ;absolute indirect long
```
JML is to a long jump as JSL is to a long subroutine call. Eyes & Lichty show JML [<addr>] as syntactically correct, which it isn't. The brackets are what define the addressing mode (absolute indirect long), not the mnemonic.

In Supermon 816's assembler, JMP mnemonics use 16-bit addresses only, which greatly eased instruction parsing. JML has to be used if a 24-bit address is to be assembled with the instruction. This arrangement makes JML $000000 assemble as 5C 00 00 00.
JML <laddr> (opcode $5C) will not assemble for any value of <laddr>. JMP <laddr> does assemble, but without JML, there is no way to code an inter-bank jump if the target bank is $00.
JSL <laddr> (opcode $22) will not assemble with any value of <laddr> that is less than $00FFFF.

When time permits, I will go through one my POC V1's firmware source files and replace my 816 macros with the WDC format equivalents and see how it assembles.

Posted: **Mon Nov 23, 2020 4:06 pm**

BigDumbDinosaur wrote:

Some things I noted during testing:

1. The problem with the source code editor not recognizing previous settings is back. I seem to recall it has to do with a registry setting.

This time it is intentional. I have moved from version 1.2 to 1.3. The flag to determine which processor is in use also changed from BOOL to UINT8 as I now have 3 choices vs. 2. This would not allow the sharing of registry settings between the 2 versions. You can copy your registry settings using regedit.
I will post those steps separately.

Quote:

2. There doesn't seem to be an unambiguous way to tell the assembler to assemble an immediate mode operand as 16 bits when the MSB is $00. In the WDC assembler there is are pseudo-ops to deal with that, but I think that method is ill-advised. Better would be an operator to tell the assembler to promote an operand less than $0100 to 16-bits. In my Supermon 816 program I use !#<operand> to force a 16-bit assembly when the MSB is $00.

It should be possible to use that notation, but I'll have to dig into the code some more to be sure.

Quote:

3. Regarding jump instructions ... JMP mnemonics use 16-bit addresses only, which greatly eased instruction parsing. JML has to be used if a 24-bit address is to be assembled with the instruction. This arrangement makes JML $000000 assemble as 5C 00 00 00.

4. JML <laddr> (opcode $5C) will not assemble for any value of <laddr>. JMP <laddr> does assemble, but without JML, there is no way to code an inter-bank jump if the target bank is $00.

I actually read that from the 65816 datasheet about using JML for absolute long, but didn't connect the implications of not using it. This will be an easy change to make as it only involves some data table updates.

Quote:

5. JSL <laddr> (opcode $22) will not assemble with any value of <laddr> that is less than $00FFFF.

I will have to find a place to override the coding for this as a 2 byte operand is simply not valid.

Thank you very much for the help with testing. I want this to be a reliable tool and the more code we can pass through it successfully, the better it will be for everyone.

Daryl

Posted: **Mon Nov 23, 2020 4:29 pm**

To copy your registry setting from Version 1.2 to version 1.3, do the following using REGEDIT:

1. Locate the 1.2 key. Its path should be HKEY_CURRENT_USER\SOFTWARE\MiKSoft\6502 Simulator

: reg2.png (2.45 KiB) Viewed 34950 times

2. Right Click on the 1.2 key folder and select export. Save it to a place you will remember, i.e. the Desktop. You can name it 1.2

3. If there is a 1.3 key already there, right-click on it and select delete.

4. Right-click on the 1.2 key again and select Rename. Change the name to 1.3

5. Now, find the exported key that you made in step 2 and double-click it. You have to click yes to allow it to make changes and yes again to accept the warning about making registry changes. You should get a message saying the contents were updated successfully.

: reg.png (3.01 KiB) Viewed 34950 times

6. You should now see both 1.2 and 1.3 keys in the 6502 Simulator folder.

7. You can delete the exported key you saved from step 2. It is no longer needed.

When you start the 1.3 version, it should have all the settings from 1.2. The processor will be either the 6502 or 65c02, but may not match what you had in 1.2. That is ok, just make your selection and start using the program.

Daryl

Posted: **Mon Nov 23, 2020 10:08 pm**

8BIT wrote:

BigDumbDinosaur wrote:

...1. The problem with the source code editor not recognizing previous settings is back. I seem to recall it has to do with a registry setting.

This time it is intentional.

Ah-so! I fixed up the registry and things are back to normal.

Quote:

2. There doesn't seem to be an unambiguous way to tell the assembler to assemble an immediate mode operand as 16 bits when the MSB is $00...In my Supermon 816 program I use !#<operand> to force a 16-bit assembly when the MSB is $00.

It should be possible to use that notation, but I'll have to dig into the code some more to be sure.

! is used for negation, so there might be a problem with using it to indicate coercion of a 16-bit value. An alternate syntax could be `#<operand>, since the grave accent is not an operator.

Quote:

Thank you very much for the help with testing. I want this to be a reliable tool and the more code we can pass through it successfully, the better it will be for everyone.

So far, it's looking good.

Here's another one for you. Both MVN and MVP are assembling "backwards." For MVN, the official language syntax is MVN <source>,<destination>, where <source> and <destination> are treated as 24-bit addresses. Ditto for MVP. Assuming the instruction MVN $023456,$AB7890 is being assembled, the resulting machine code should be $54 $AB $02. Note that the destination bank is the first operand. However, the assembler has them reversed.

Incidentally, MVN and MVP are not considered to be immediate mode instructions. Hence # should not be part of the source syntax.

Posted: **Mon Nov 23, 2020 11:36 pm**

The following code will assemble in version 1.2.14 but not in version 1.3.0:

Code: Select all

nxpctdlo =<[nxctscal/hz]       ;underflows/sec LSB

The assembler halts with the error:

ERROR E017: Missing constant value (number, label, function or '*'). ROW 49, FILE P:\65816.d\poc_series\v1\1.11.d\4.d\include_hardware\nxp\data.asm

In both cases, the PROC65C02 option is set in the main source file. Some testing revealed that the assembler errors out trying to evaluate [nxctscal/hz].

Posted: **Mon Nov 23, 2020 11:39 pm**

I'm glad the registry procedure worked for you!

I was able to build the !# combination for forcing 16-bit immediate values. ! still works as negate as does != for not equal.

I also have corrected items 3,4, & 5. This includes elevating BYTE sized variables in the JMP and JSL opcodes to 24 bits.

I will reverse the operands for the MVN and MVP opcodes. The assembler's parser is not set up for parsing 2 values on the operands. Michal was able to do it for the BBR/BBS and RMB/SMB opcodes for the 65C02 using the # for the first operand (bit selector).

I based my syntax off of of Bruce Clark's tutorial -> http://6502.org/tutorials/65c816opcodes.html#6.6 which does use # in the operands. Since the lower 16-bits of the source and destination are stores in X&Y and can be changed during runtime, it does not add any value to use a full 24-bit value in the source.

But, I have verified that this syntax will allow the use of variables to provide the source and destination banks:

Code: Select all

src = $123456
dest = $abcdef
       MVN #src>>16, #dest>>16

I will clean up the code and release an updated version soon.

thanks again for your help!

Daryl

Posted: **Tue Nov 24, 2020 1:41 am**

BigDumbDinosaur wrote:

The following code will assemble in version 1.2.14 but not in version 1.3.0:

Code: Select all

nxpctdlo =<[nxctscal/hz]       ;underflows/sec LSB

The assembler halts with the error:

ERROR E017: Missing constant value (number, label, function or '*'). ROW 49, FILE P:\65816.d\poc_series\v1\1.11.d\4.d\include_hardware\nxp\data.asm

In both cases, the PROC65C02 option is set in the main source file. Some testing revealed that the assembler errors out trying to evaluate [nxctscal/hz].

Oof - I forgot to mention, I had to make another compromise. [] was used to bracket expressions, but now I need it to identify Indirect Long modes. So, I assigned {} as the brackets for expressions. I'll see if these are mentioned in the help files and update them.

I tried your code with {} and the error disappeared.

I do not think there were any other changes, but I will try to document them all and any future ones in the help, now that I can recompile it when needed.
I did add all the new opcodes and changes to .opt in the Dynamic Help window, so please do check it out and let me know if you find any blunders there also. I'm starting to go a little batty with all this code, so fresh eyes are very helpful.

Daryl

Posted: **Tue Nov 24, 2020 2:00 am**

8BIT wrote:

I was able to build the !# combination for forcing 16-bit immediate values. ! still works as negate as does != for not equal.

Good!

Quote:

I will reverse the operands for the MVN and MVP opcodes. The assembler's parser is not set up for parsing 2 values on the operands. Michal was able to do it for the BBR/BBS and RMB/SMB opcodes for the 65C02 using the # for the first operand (bit selector).

I based my syntax off of of Bruce Clark's tutorial -> http://6502.org/tutorials/65c816opcodes.html#6.6 which does use # in the operands. Since the lower 16-bits of the source and destination are stores in X&Y and can be changed during runtime, it does not add any value to use a full 24-bit value in the source.

Bruce's syntax is contrary to both WDC's and Eyes & Lichty. Here's what the latter has written:

Quote:

As a result, the recommended assembler syntax is to follow the
mnemonic first with a 24-bit source address then with a 24-bit destination
address—or more commonly with labels representing code or data
addresses. The assembler strips the bank byte from each address (ignoring
the rest) and inserts them in the correct object code sequence. (Destination
bank, source bank.) For example:

440102 MVP SOURCE,DEST move from bank of source(02) to bank of dest(01)

(Page 132.)

Quote:

But, I have verified that this syntax will allow the use of variables to provide the source and destination banks:

Code: Select all

src = $123456
dest = $abcdef
       MVN #src>>16, #dest>>16

That would work, albeit somewhat convoluted. It would probably be best to bury it in a macro, e.g.:

Code: Select all

;memcp: BLOCK COPY MEMORY USING MVN
;
memcp    .macro .s,.d,.q       ;source address, destination address, bytes to copy
;
;	.S & .D are assumed to be 24-bit addresses
;	.Q is the quantity of bytes to be copied.
;
         .if .q                ;if bytes to copy > 0...
         php                   ;save MPU state
        (sei                   ;kill IRQs, optional, may improve performance)
         phb                   ;save current data bank
         rep #%00110000        ;16-bit registers
         lda !#.q-1            ;bytes to copy, coerced to 16-bits
         ldx !#.s & $FFFF      ;source address LSW
         ldy !#.d & $FFFF      ;destination address LSW
         mvn .s >> 16,.d >> 16 ;source bank, destination bank
         plb                   ;restore data bank
         plp                   ;restore MPU state
         .endif
         .endm

Quote:

Oof - I forgot to mention, I had to make another compromise. [] was used to bracket expressions, but now I need it to identify Indirect Long modes. So, I assigned {} as the brackets for expressions. I'll see if these are mentioned in the help files and update them.

So curly braces ({}) are used to establish algebraic precedence in expressions, brackets ([]) are used to identify indirect long addressing and parentheses are unchanged. That should work.

Do you have an updated version to post?

Posted: **Tue Nov 24, 2020 2:03 am**

BigDumbDinosaur wrote:

Do you have an updated version to post?

Soon, hopefully later tonight.

Daryl

Posted: **Tue Nov 24, 2020 3:51 am**

Here is the latest update. V1.3.1

It has all the fixes for things BigDumbDinosaur and I have found so far.

Please try to break it! (and tell me when you do)

thanks!

Daryl

Posted: **Tue Nov 24, 2020 4:54 am**

8BIT wrote:

Here is the latest update. V1.3.1

It has all the fixes for things BigDumbDinosaur and I have found so far.

Please try to break it! (and tell me when you do)

thanks!

Daryl

Downloaded.

I'm going to convert all of the POC V1.2 firmware source files to recognize the new features and then see if it will assemble. At present, that is about 13,000 lines total...it will be slightly less after the changes.

6502.org

Kowalski Simulator Updates

Re: Kowalski Simulator Updates

Re: Kowalski Simulator Updates

Re: Kowalski Simulator Updates

Re: Kowalski Simulator Updates

Re: Kowalski Simulator Updates

Re: Kowalski Simulator Updates

Re: Kowalski Simulator Updates

Re: Kowalski Simulator Updates

Re: Kowalski Simulator Updates

Re: Kowalski Simulator Updates

Re: Kowalski Simulator Updates

Re: Kowalski Simulator Updates

Re: Kowalski Simulator Updates

Re: Kowalski Simulator Updates

Re: Kowalski Simulator Updates