6502.org • View topic - Kowalski Simulator Updates

View unanswered posts | View active topics

Board index » 6502.org Users Forum » Emulation and Simulation

All times are UTC

Kowalski Simulator Updates

Page 5 of 23

[ 340 posts ]

Go to page Previous 1, 2, 3, 4, 5, 6, 7, 8 ... 23 Next

Previous topic | Next topic

Author

Message

8BIT

Post subject: Re: Kowalski Simulator Updates

Posted: Sun Nov 22, 2020 8:04 pm

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA

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

Attachments:

File comment: sample source file

OPC_testL.asm [9.18 KiB]
Downloaded 59 times

File comment: Revised v1.2.15 version with fixed Help

6502 v1.2.15.zip [604.68 KiB]
Downloaded 54 times

_________________
Please visit my website -> https://sbc.rictor.org/

Last edited by 8BIT on Tue Nov 24, 2020 3:47 am, edited 1 time in total.

Top

BigDumbDinosaur

Post subject: Re: Kowalski Simulator Updates

Posted: Sun Nov 22, 2020 9:43 pm

Joined: Thu May 28, 2009 9:46 pm
Posts: 8197
Location: Midwestern USA

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 @?

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Top

8BIT

Post subject: Re: Kowalski Simulator Updates

Posted: Mon Nov 23, 2020 1:19 am

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA

The default is still @, but just add

Code:

.opt SwapBin

to your source and it will be reversed.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Top

8BIT

Post subject: Re: Kowalski Simulator Updates

Posted: Mon Nov 23, 2020 4:38 am

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA

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

_________________
Please visit my website -> https://sbc.rictor.org/

Top

BigDumbDinosaur

Post subject: Re: Kowalski Simulator Updates

Posted: Mon Nov 23, 2020 9:57 am

Joined: Thu May 28, 2009 9:46 pm
Posts: 8197
Location: Midwestern USA

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:
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:
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.

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Top

8BIT

Post subject: Re: Kowalski Simulator Updates

Posted: Mon Nov 23, 2020 4:06 pm

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA

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

_________________
Please visit my website -> https://sbc.rictor.org/

Top

8BIT

Post subject: Re: Kowalski Simulator Updates

Posted: Mon Nov 23, 2020 4:29 pm

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA

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

Attachment:

reg2.png [ 2.45 KiB | Viewed 29146 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.

Attachment:

reg.png [ 3.01 KiB | Viewed 29146 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

_________________
Please visit my website -> https://sbc.rictor.org/

Top

BigDumbDinosaur

Post subject: Re: Kowalski Simulator Updates

Posted: Mon Nov 23, 2020 10:08 pm

Joined: Thu May 28, 2009 9:46 pm
Posts: 8197
Location: Midwestern USA

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.

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Top

BigDumbDinosaur

Post subject: Re: Kowalski Simulator Updates

Posted: Mon Nov 23, 2020 11:36 pm

Joined: Thu May 28, 2009 9:46 pm
Posts: 8197
Location: Midwestern USA

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

Code:

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].

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Top

8BIT

Post subject: Re: Kowalski Simulator Updates

Posted: Mon Nov 23, 2020 11:39 pm

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA

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:

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

_________________
Please visit my website -> https://sbc.rictor.org/

Top

8BIT

Post subject: Re: Kowalski Simulator Updates

Posted: Tue Nov 24, 2020 1:41 am

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA

BigDumbDinosaur wrote:

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

Code:

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

_________________
Please visit my website -> https://sbc.rictor.org/

Top

BigDumbDinosaur

Post subject: Re: Kowalski Simulator Updates

Posted: Tue Nov 24, 2020 2:00 am

Joined: Thu May 28, 2009 9:46 pm
Posts: 8197
Location: Midwestern USA

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:

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:

;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.  Note that if .Q = 0 no copy will occur.
;
         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
         .endm

Quote:

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?

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Top

8BIT

Post subject: Re: Kowalski Simulator Updates

Posted: Tue Nov 24, 2020 2:03 am

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA

BigDumbDinosaur wrote:

Do you have an updated version to post?

Soon, hopefully later tonight.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Top

8BIT

Post subject: Re: Kowalski Simulator Updates

Posted: Tue Nov 24, 2020 3:51 am

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA

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

Attachments:

File comment: Version 1.3.1 with 65816 assembler support.

6502 v1.3.1.zip [611.8 KiB]
Downloaded 51 times

_________________
Please visit my website -> https://sbc.rictor.org/

Top

BigDumbDinosaur

Post subject: Re: Kowalski Simulator Updates

Posted: Tue Nov 24, 2020 4:54 am

Joined: Thu May 28, 2009 9:46 pm
Posts: 8197
Location: Midwestern USA

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.

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Top

Page 5 of 23

[ 340 posts ]

Go to page Previous 1, 2, 3, 4, 5, 6, 7, 8 ... 23 Next

Board index » 6502.org Users Forum » Emulation and Simulation

All times are UTC

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum