6502.org

Posted: **Mon Jun 25, 2018 9:20 pm**

Guus Assmann wrote:

Thanks for the help so far, I've learnt something again.

Still the assembly program is not behaving.
So I've uploaded the complete source code.
What's wrong? The 2nd pass of the assembly errs out at line 362.
It claims that the label "output" is not defined.
But it most definitively is.
And I tried different names as well. Same problem.
For test, I also made a comment out of this instruction.
Then it goes one line more and the same error for "in"
This is the case for almost all the jmp instructions. (Reset en NMI go ok, as do a couple more)

BTW: I've also seen that adding .b or .f with a label in the BNE or BEQ doesn't work in this assembler. (I'll correct that)

Code: Select all

sec1.20		.ds 1		;Count 1/20 of seconds

The above label name is not acceptable to the assembler. Label and symbol names may contain alphanumeric characters and the underscore. Local label and symbol names are preceded by a period, as in .local_label.

Klaus mentioned the cascading effect that one error can have on subsequent assembly. It could be the erroneous label sec1.20 is the primary cause of assembly failure.

Code: Select all

enemi	jmp	[nmivector]	;indirect NMI JMP
ierqu	jmp	[irqvector]	;indirect IRQ JMP

An indirect jump is indicated with parentheses, not brackets. Both of the above instructions will evaluate to jumps, not indirect jumps. In the Kowalski assembler, brackets are used to alter evaluation precedence in arithmetic expressions. The correct way to write the above is:

Code: Select all

enemi	jmp	(nmivector)	;indirect NMI JMP
ierqu	jmp	(irqvector)	;indirect IRQ JMP

Posted: **Tue Jun 26, 2018 7:40 am**

Just before the label int there is a .end in the middle of the code. Guus probably found it by now. I was wondering why the editor would not complain about labels starting with a number. So I went for the first appearance of such label and found the .end just a few lines ahead.

Posted: **Tue Jun 26, 2018 8:19 am**

Klaus2m5 wrote:

Just before the label int there is a .end in the middle of the code. Guus probably found it by now. I was wondering why the editor would not complain about labels starting with a number. So I went for the first appearance of such label and found the .end just a few lines ahead.

I had tried assembling his source and it bombed where the sec1.20 label was defined. I didn't read beyond that point, so that was a good catch on your part, Klaus.

Posted: **Tue Jun 26, 2018 4:43 pm**

Up till now, I've found quite a number of problems.
To do this, I took the various parts of the code and assembled them one at the time.
A lot of missing labels I added for test.
This way I found many things. But now it also behaves as it should and indicates what's wrong.
I still have to solve a number of issues.
And there's some things I find strange.
Like CMP #,"A" is not possible.
But:
A ="A"
CMP #,A
This does work......

Thanks for the help.
Guus

Posted: **Tue Jun 26, 2018 5:03 pm**

Quote:

Like CMP #,"A" is not possible.

Use single quotes and no comma!

Code: Select all

   CMP #'A'

Posted: **Thu Jun 28, 2018 10:17 am**

Today I've solved another misery.
The assmbler would crash after the 2nd pass. "Program has stopped working"
It was caused by the path to the listing being invalid(From a previous setting on a memory stick)
The place to do this is attached.
(And it was a nuicance to find.

)

BR/
Guus

Posted: **Sun Jul 29, 2018 2:08 pm**

Hello,

Looks like I found a bug in the assembler. (Or did I do something wrong?
This bit of code:
CLI
BRK
;
nop
nop
Compiles into:
00119 0833 58 CLI
00120 0834 00 00 BRK
00122 ;
00123 0836 EA nop
00124 0837 EA nop

And if I do:
CLI
.db $00 ; BRK
;
nop
nop
Then I get:
00119 0833 58 CLI
00121 .db $00 ; BRK
00122 ;
00123 0835 EA nop
00124 0836 EA nop

The first part, using the BRK instruction compiles into two bytes.
And I think it should be just one byte, like I get using the .DB directive.

Any comment is welcome.

BR/
Guus

Posted: **Sun Jul 29, 2018 2:15 pm**

The BRK instruction does have an operand - that is, it is a length 2 instruction - so I think that's correct. The operand is not used by the processor but can be inspected by the BRK handling code. Many systems don't bother, so it's easy to get the impression that BRK is a single byte.

Edit: arguably, an assembler should insist that BRK in the source has an operand byte with it. Maybe that's the bug.

Posted: **Sun Jul 29, 2018 4:37 pm**

Guus Assmann wrote:

The first part, using the BRK instruction compiles into two bytes. And I think it should be just one byte, like I get using the .DB directive.

As Ed noted, BRK (and COP in the 65C816) is a two-byte instruction—the WDC data sheet actually mentions this. However, in the Kowalski simulator, there is an option to make it assemble (not compile!) BRK without a signature byte. Click on Simulator on the menu bar, select Options and then click the Assembler tab in the dialog box that will open. Near the bottom of the dialog box you will see the appropriate check boxes.

Posted: **Sun Jul 29, 2018 7:53 pm**

Most assemblers I'm aware of assemble BRK without an operand and as a single byte, leaving the programmer to postfix the operand if required using data directives. Of course it's the BRK handler's responsibility to read and interpret the operand if required.

It would indeed be logical to assemble "BRK #0" as 00 00, and some assemblers accept that syntax, but that's not what was specified here. This difference from standard assembler behaviour could indeed be considered a bug.

Posted: **Sun Jul 29, 2018 7:58 pm**

Mmm, I think you may be right about assemblers. Maybe the idea of BRK having an operand is a specialised pedantic fact which isn't helpful even though it's "true"!

Posted: **Sun Jul 29, 2018 8:02 pm**

Chromatix wrote:

It would indeed be logical to assemble "BRK #0" as 00 00, and some assemblers accept that syntax, but that's not what was specified here. This difference from standard assembler behaviour could indeed be considered a bug.

In the case of the Kowalski assembler, it's not a bug. It's a design feature that gives the programmer the option to have any signature byte assembled after a BRK instruction. The default if this feature is enabled is to assemble $EA (NOP) as the signature byte. If this feature is disabled, only $00 will be assembled for a BRK instruction.

Posted: **Sun Jul 29, 2018 8:33 pm**

(Hmm, I note with a little surprise that the BBC Basic assembler allows - and ignores - a single operand for BRK - and for all the others like RTS and TXA! Very forgiving.)

Posted: **Sun Jul 29, 2018 8:43 pm**

In this particular case, I have taken a listing from a program that was written in 1982:
AS65 Assembler for R6502 [1.11]. Page 1
--------------------------------- DCFORG.ASM ---------------------------------

;from E l e k t u u r april 1982 p.4-40
;for Universele tijdsein-processor (with

And there the BRK instruction was codes as just one byte 00, followed by two NOP instructions.
The timeframe suggests, that the 65C816 was non existend.
Maybe the 65C02 was? But I couldn't afford that back then.

As I wanted to see if I can change this program, I thought the Macroassembler would be a nice tool.
I've not yet had a look at how the program, or this bit of code works.

BR/
Guus

Posted: **Sun Jul 29, 2018 8:49 pm**

BigDumbDinosaur wrote:

Chromatix wrote:

It would indeed be logical to assemble "BRK #0" as 00 00, and some assemblers accept that syntax, but that's not what was specified here. This difference from standard assembler behaviour could indeed be considered a bug.

In the case of the Kowalski assembler, it's not a bug. It's a design feature that gives the programmer the option to have any signature byte assembled after a BRK instruction. The default if this feature is enabled is to assemble $EA (NOP) as the signature byte. If this feature is disabled, only $00 will be assembled for a BRK instruction.

Except that that's demonstrably *not* what happens here, and it makes it *more* difficult to assemble an arbitrary desired trailing byte.

The code given was

Code: Select all