Kowalski Simulator Updates

[BigDumbDinosaur]

8BIT wrote:

Do your system have RAM at $CFFF? That area is listed as IO Block in your source.

Code: Select all

         ldx !#hwstack         ;set top of...
         txs                   ;MPU stack

If there is no RAM there, then its possible some of your code is might be causing a longer loop.

The memory map for the $00Cxxx block is I/O from $00C000 to $00C37F, undecoded from $00C380 to $00C3FF, and RAM from $00C400 to $00CFFF.

Quote:

For instance, this code might be affecting I, M or X flags.

Code: Select all

         lda #%00100100
         pha                   ;do MPU...
         plp                   ;test setup...

PLP might be pulling other bits if the stack points to non-RAM.

After coming out of reset and thus with the MPU in emulation mode, it is implied that SP will be $01xx. Hence the above push-and-pull should work on the first pass.  Shortly afterward, when the MPU has been switched to native mode and SP is set to $CFFF, it will still be pointing to RAM.  So the above will work no matter what.

I did verify with my GAL test rig that the GAL in POC V1.4 is correctly decoding the memory map.

Quote:

I'm working on the corrections and found another issue. The syntax checker in the editor flags the REP and SEP commands with error 6 if you press enter on either line. This is because the syntax checker assembles just the one line without knowledge of the assembler options - SwapBin included. I need to work out how to fix that, maybe adding another registry option on the assembler options to set SwapBin.

I actually have not used the syntax checker, so I was unaware there was a problem with SwapBin.  I just let the assembler report syntax issues and fix them all at the same time. 

[8BIT]

I have update the simulator to fix the PEA #$1234 error, the issue with the Y register not updating correctly, cleared the B bit when in 65816 native mode, and fix issues with "Casesensitive" assembler options and added "SwapBin" support to the Assembler Options tab with Registry storage.

Version 1.4.0.5 is now on my website. https://sbc.rictor.org/kowalski.html

thanks!
Daryl

[BigDumbDinosaur]

8BIT wrote:

I have update the simulator to fix the PEA #$1234 error, the issue with the Y register not updating correctly, cleared the B bit when in 65816 native mode, and fix issues with "Casesensitive" assembler options and added "SwapBin" support to the Assembler Options tab with Registry storage.

Version 1.4.0.5 is now on my website. https://sbc.rictor.org/kowalski.html

Downloaded.  I will give it a test later on this evening...if I can stay awake. 

[Yuri]

Updated the GitHub repo:
https://github.com/Kelmar/kowalski/rele ... on_1.4.0.5

[gregorio]

Hi. I started using Kowalski Simulator, it's a very good tool, but I ran into a problem. I have set the input/output to address 0x7F00, where sending data involves writing it to port 0x7f00 and receiving it by reading it from port 0x7f00. It turns out that the terminal built into Kowalski Simulator doesn't work when I enter data into 0x7f00, but works when I enter it into 0x7f01. This forces me to compile two versions of the program, one to check its operation in KS, and the other for my system. Is there an easy way to bypass this problem?
Not working code:

Code: Select all

*=$0300
 LDA #$41
 STA $7f00
 BRK
 

Working code:

Code: Select all

*=$0300
 LDA #$41
 STA $7f01
 BRK
 

[8BIT]

Hello Gregoria,
The answer is yes and no.

For output, you can set the IO area in the Simulator options to $7EFF. This will allow writing characters to $7F00. There may be some side affects if you are using RAM in page $7Exx.

But, input will not be from $7F00. Input is from IO_AREA+4, so in this case it will be $7F03. You will not be able to do both from the same address.

You can set your IO addresses as variables at the top of your code and then you can just change those to assemble for System or Simulator.

Code: Select all

; IO_Page = $7F00
cout = $7F01
cin = $7F04

...

     lda #'A'
     JSR cout

input jsr cin
        beq input
        rts

Daryl

[gregorio]

Thank you for the explanation. I have another problem with Kowalski Simulator. How do I save a binary image file larger than 64kB?

[BigDumbDinosaur]

gregorio wrote:

How do I save a binary image file larger than 64kB?

Use Ctrl-K to open the save program dialog, select binary image, select Options to set the desired memory range in hex (0x0000 - 0x1FFFF would save 128K) and then save the file.  You can subsequently load the saved binary by using Ctrl-L, selecting binary image, etc.

[BigDumbDinosaur]

Attached is something I’ve been working on that will assemble fine if the origin is in bank $00, but not if in a higher bank.  The origin statement is at line 349, the first error is reported at line 422 if assembling to other than bank $00.  Adding a \2 to the address part of the operand will correct the problem, but other similar errors will pop up.  I seem to recall we ran into this in the past and it was corrected.

loader.asm

(43.34 KiB) Downloaded 285 times

[8BIT]

ok, will look into the JMP bug and still need to address the BCD math issues.

Daryl

[BigDumbDinosaur]

8BIT wrote:

ok, will look into the JMP bug and still need to address the BCD math issues.

Thanks for looking at it.

This is not a bug report, just something about which I am curious.  It is possible to enter some non-ASCII characters in the editor using various ALT-<Keypad> combinations, such as é, æ, µ, etc., but not the standard DOS box drawing characters, e.g.:

Code: Select all

╔═══╦═══╗
║   ║   ║
║   ║   ║
║   ║   ║
╚═══╩═══╝

Is there something in the editor that doesn’t like those?  Being able to draw those would be handy now and then for comments.

[BigDumbDinosaur]

I recently discovered that the 65C816’s WDM instruction doesn’t appear to be correctly handled by the assembler.  WDM is a two-byte instruction; the second byte is not optional, as it is part of the instruction.  The assembler will not allow WDM to be assembled with the second byte.  The execution of WDM during simulation does add $02 to PC, which means code such as...

Code: Select all

	.opt proc65816,caseinsensitive,swapbin
	*=$02000
	wdm
	lda #1
	brk
	.end

...will execute as expected.  Here’s what the assembler put into the listing file:

Code: Select all

002000  42            	wdm
002002  A9 01         	lda #1
002004  00            	brk

Notice that nothing apparently was assembled at $002001.  However, examination of the object output reveals:

Code: Select all

002000  42
002001  00
002002  A9 01
002004  00

So the assembler is silently inserting a second byte.

The reason for this curiosity on my part is I was looking to use WDM as a “spacer” in self-modifying code, taking advantage of the fact that WDM acts as a NOP.  However, my plan requires that I be able to specify the second byte.  The best-laid plans of men and mice... 

[8BIT]

In my research into the WDM instruction, all the references say WDM is reserved for future use and should not be used as it would break future compatibility. I was tempted to exclude it from the 816 opcode list based on that statement and let it just return an invalid opcode. In the end, I decided to add it with the hard coded $00. Since the addressing mode is not defined, I did not allow any entry of an operand.

From Bruce Clark's 65816 opcode description, he suggests using WDM in the same way as the BIT # trick for skipping an opcode.

Code: Select all

LABEL1 INX
       DB  $42 ;WDM opcode
LABEL2 DEX

Using this format, the code will assemble without the hard-coded $00.

I do not have plans to modify the assembler behavior of the WDM instruction.

I am still working on the previous bug concerning absolute operands above Page $00, just have not had much time this month. I hope to have some time over the holidays.

Daryl

[gregorio]

I wonder if it would be a good idea to add

Code: Select all

WDM #nn

to assembler?

[BigDumbDinosaur]

gregorio wrote:

I wonder if it would be a good idea to add

Code: Select all

WDM #nn

to assembler?

That syntax would be incorrect, as the second byte associated with WDM is part of the instruction.  The WDM opcode ($42) is understood to be the prefix to an extended instruction, the second byte defining what that instruction is.  WDM #nn would imply that nn is data of some sort, which it isn’t.

Exactly what Bill Mensch had planned for the WDM opcode is unknown (to me, at least).  It has always seemed logical to me to use it to flag instructions that are to load/store/manipulate 16-bit quantities, in lieu of having to clear/set the m and x bits in SR with REP and SEP.  For example, a 16-bit, immediate-mode accumulator load could be...

Code: Select all

42 A9

...followed by the operand.  The 65C816 would understand that $A9 is the load-immediate opcode, as always, but the $42 prefix means a word is to be loaded instead of a byte.  Similarly, INC $1234, when intended to increment the quantity at $1234 and $1235 (16-bit increment), would be coded...

Code: Select all

42 EE 34 12

...which is more elegant than fiddling with REP and SEP.

It’s all academic, of course.  Further development of any part of the 6502 family at this time is highly unlikely.  Bill Mensch will be 80 years young in February.  I’d be mildly surprised if he still comes into the office with any regularity. 

8BIT wrote:

In my research into the WDM instruction, all the references say WDM is reserved for future use...Since the addressing mode is not defined, I did not allow any entry of an operand.

Probably the best way to handle it.  My experiments on my POC unit revealed that executing WDM has absolutely no effect other than to advance PC two bytes.

Quote:

From Bruce Clark's 65816 opcode description, he suggests using WDM in the same way as the BIT # trick for skipping an opcode.

Actually, WDM is better for that purpose than using the BIT opcode for immediate or page zero addressing, as the former doesn’t affect SR.