Problem with the .MACRO function in Kowalski Simulator

Topics pertaining to the emulation or simulation of the 65xx microprocessors and their peripheral chips.
Post Reply
gregorio
Posts: 77
Joined: 07 Feb 2023

Problem with the .MACRO function in Kowalski Simulator

Post by gregorio »

I'm having trouble with the .MACRO instruction in Kowalski Simulator. I'm trying to compile the example code based on the HELP file in the latest version of the program, 1.4.0.9, and it's not working.

Code: Select all

Put: 	.MACRO chr        ; character printing
    	LDA #chr	  ;         tru ‘chr’
    	JSR PRINT
    	.ENDM

	*=$1000
start:
	CLC
	Put 'A'
PRINT:
	RTS
	*=$fffc
	.WORD start
I found an older version, 1.1.9.21, on Archive.org, and the same code compiles without any problems. What could be the cause?
User avatar
8BIT
Posts: 1787
Joined: 30 Aug 2002
Location: Sacramento, CA
Contact:

Re: Problem with the .MACRO function in Kowalski Simulator

Post by 8BIT »

That code compiled and ran ok for me in version 1.4.0.9 using all 3 processors.

What is the error or problem?



Edited: I missed the version in the OP comments
Last edited by 8BIT on Sat Mar 07, 2026 8:09 pm, edited 1 time in total.
Please visit my website -> https://sbc.rictor.org/
User avatar
BigDumbDinosaur
Posts: 9425
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Problem with the .MACRO function in Kowalski Simulator

Post by BigDumbDinosaur »

gregorio wrote:
I'm having trouble with the .MACRO instruction in Kowalski Simulator. I'm trying to compile the example code based on the HELP file in the latest version of the program, 1.4.0.9, and it's not working.

Code: Select all

Put: 	.MACRO chr        ; character printing
    	LDA #chr	  ;         tru ‘chr’
    	JSR PRINT
    	.ENDM

	*=$1000
start:
	CLC
	Put 'A'
PRINT:
	RTS
	*=$fffc
	.WORD start

I found an older version, 1.1.9.21, on Archive.org, and the same code compiles without any problems. What could be the cause?
Several things:

  1. Change the macro name Put to put and your code will assemble (not “compile”).
     
  2. Within macros, use local symbols unless you want the macro to modify a global symbol.  I would write your macro thusly:

    Code: Select all

    put      .macro .c             ;print char
             lda #.c               ;.c is a local symbol, unknown...
             jsr print             ;outside of the macro invocation
             .endm
    Each invocation of the put macro will work with a fresh version of .c, which will only be known to that invocation.
     
  3. To make sure the assembler agrees with what you want, I recommend you place a statement such as the following in your source file as the very first line...before anything else:

    Code: Select all

             .opt proc65c02,caseinsensitive,swapbin
    What the above does is tell the assembler that the 65C02 instruction set is syntactically correct, unquoted text, other than macro names, is case-insensitive, and % is recognized as the binary radix, per the official MOS Technology assembly language standard.  Read the help screen for the .opt pseudo-op for the available options.
     
  4. Labels, such as print or start do not need to be followed by a colon.  Ditto for macro names.
     
  5. As a matter of good style and readability, you should avoid mixing case in your code, other than quoted strings or characters, of course.  Also, column alignment in your source code will produce column alignment in your listings, which will help with readability.
Last edited by BigDumbDinosaur on Sun Mar 15, 2026 12:00 pm, edited 1 time in total.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
gregorio
Posts: 77
Joined: 07 Feb 2023

Re: Problem with the .MACRO function in Kowalski Simulator

Post by gregorio »

Error information:
ERROR E037: Unrecognized instruction/directive/macro name.

I've checked now.
It seems the error occurs if the macro name begins with a capital letter.
User avatar
8BIT
Posts: 1787
Joined: 30 Aug 2002
Location: Sacramento, CA
Contact:

Re: Problem with the .MACRO function in Kowalski Simulator

Post by 8BIT »

OK, if the Case Sensitive option is enabled, there is no error message. With case-insensitive selected, I see the same error message.
Screenshot 2026-03-07 170938.jpg
Screenshot 2026-03-07 170938.jpg (34.8 KiB) Viewed 586 times
I'll take a look at the code when I get some time.

thanks for pointing it out!

Daryl
Please visit my website -> https://sbc.rictor.org/
gregorio
Posts: 77
Joined: 07 Feb 2023

Re: Problem with the .MACRO function in Kowalski Simulator

Post by gregorio »

You're welcome.
I have another problem with .MACRO.

Code: Select all

puta: 	.MACRO A     
    	 .DB $DB,<.beta,>.beta
    	 .RS A
  .beta:
  	nop
    	.ENDM
Error: ERROR E037: Unrecognized instruction/directive/macro name. ROW 4, FILE
User avatar
8BIT
Posts: 1787
Joined: 30 Aug 2002
Location: Sacramento, CA
Contact:

Re: Problem with the .MACRO function in Kowalski Simulator

Post by 8BIT »

Code: Select all

puta:    .MACRO A     
        .DB $DB,<.beta,>.beta
        .RS A
.beta:
     nop
       .ENDM
Move the label ".beta:" all the way to the left and it will work. Labels must start in the first column of the line, even in macros.
Please visit my website -> https://sbc.rictor.org/
gregorio
Posts: 77
Joined: 07 Feb 2023

Re: Problem with the .MACRO function in Kowalski Simulator

Post by gregorio »

Thanks
I'm trying to write a macro that would allow me to ensure that 32-bit data always starts at an address divisible by 4, i.e., xxx0, xxx4, xxx8, xxxC.

Code: Select all

blabla .MACRO
; If necessary, the macro should insert the appropriate number of NOPs here
STP
.DWORD $12345678 ;must be at ADDRESS /4
.ENDM 
The macro should insert the appropriate number of NOP instructions before STP to place a 32-bit value at an address divisible by 4.
Is this possible?
User avatar
BigDumbDinosaur
Posts: 9425
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Problem with the .MACRO function in Kowalski Simulator

Post by BigDumbDinosaur »

gregorio wrote:
I'm trying to write a macro that would allow me to ensure that 32-bit data always starts at an address divisible by 4, i.e., xxx0, xxx4, xxx8, xxxC...The macro should insert the appropriate number of NOP instructions before STP to place a 32-bit value at an address divisible by 4.

Is this possible?
Yes.  Use the modulo operator to determine if PC/4 is zero (where PC is the program counter, e.g., PC  =  *) and the .REPT pseudo-op to insert NOPs as needed.

BTW, why STP?
x86?  We ain't got no x86.  We don't NEED no stinking x86!
gregorio
Posts: 77
Joined: 07 Feb 2023

Re: Problem with the .MACRO function in Kowalski Simulator

Post by gregorio »

Thanks for the help, I wrote this macro:

Code: Select all

puta: .MACRO b
.a .=<* & $03
	.IF .a==0
        NOP
    	.ENDIF
    	.IF .a==2
	NOP
	NOP
	NOP
    	.ENDIF
    	.IF .a==3
    	NOP
    	NOP
    	.ENDIF
    	.DB $DB,<.beta,>.beta
   	 .RS b
.beta:
    .ENDM
It may not be perfect, but it seems to meet my needs, and I learned something along the way.

Why STP?
I'm building a 65c816/65c02 emulator on an STM32H750 microcontroller and want to access all its I/Os from a 65xx program. I thought STP code would be perfect for this, even if I changed its behavior slightly.
Since the real 65c02/65c816 pauses and waits for RESET after entering the STP code, I can use it to execute 32-bit ARM code and then return to the emulator.
Such code could, for example, reconfigure I/Os, change the STM32 clock speed, set serial parameters, or even use the ARM to perform calculations, etc.
User avatar
BigDumbDinosaur
Posts: 9425
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Problem with the .MACRO function in Kowalski Simulator

Post by BigDumbDinosaur »

Your macro is too “busy”.  :D  I’m not going to rewrite it for you, but look at the following bit of code for some ideas.  Be sure the .opt swapbin assembler feature is enabled when you play around with it.

Code: Select all

         .rept {{4-{*@4}}*{{*@4}!=0}}
         nop
         .endr
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Post Reply