64tass assembler peculiarity

[BigDumbDinosaur]

barrym95838 wrote:

BigDumbDinosaur wrote:

TASS is yet another example of an assembler written by someone who evidently didn't know that, at least in the 6502 universe, a standard does exist for the assembly language.

... or maybe he or she knew, but decided to follow a more unique path, for any reason under the Sun. You must be aware that variety is the spice of life, BDD!

In food, cars, motorcycles and/or women, perhaps. Not so in a software development tool or other aspects of the technical world. Look up the "least surprise" rule in software development some time.

[jim30109]

I actually like 64tass and don't think it is a bad choice. For things like writing code for ROM, I dislike the relocatable object code and linking steps. They aren't particularly complicated and it is probably more of a personal preference, but they just add an extra step and extra complexity.

Right now I'm using 64tass and generating an Intel HEX format output. I feed that into a hex2bin converter. Then I can load the whole thing into Symon Emulator and test my code. There are a few shortcoming in that, but it has let me get things tested, debugged, and mostly working quickly.

The Symon Emulator also matches well to the memory map I plan on implementing. I will have 16K of ROM, at $BFxx I'm going to decode 8 chip select lines for I/O. Below that will be RAM (actually two 32K RAM chips with the upper half of one not being using).

With Symon, I was able to get a "Hello world!" line out with an hour of tinkers with batch files to help automate parts of things. It took me about a day to convert the main parts of JMOM to assemble under 64tass and work in Symon. This is after around two decades of not touching 6502 assembly code so I don't feel too bad.

On 64tass, I will say that it just works once you figure out a few nuances. I totally agree with the "no surprises" thing, but I have yet to see two 6502 assemblers I could move seamlessly between. I think the implementation of .text instead of .byte is a consistent extension--in theory, you have to break the bytes apart, not the assembler. With basic processing, it isn't isn't unreasonable that "hi" would become the word $6869 as well as the bytes $68, $69. The .text forces you to set the context for the assembler. I would argue it is reasonable for an assembler that sees the line .byte "hi" to ask, "Did you mean that as a word? If so, it is an error. Or did you mean that as a pair of bytes? In which case I can handle it."

(64tass also evolved from the Commodore world, so "ASCII isnt ASCII" with them anyway. The ability to handle "text" in something like Commodore's modified ASCII makes a lot of sense--given that, it was almost a necessity to have something of the sort for those specific machines.)

Letting the assembler make educated decisions is okay most time, but it does have it's downfall. You can look at a post I made yesterday where 64tass balked at doing an LDY of an expression of labels that worked out to -8. In that case, it is pretty clear that something was wrong. (The logic below it branches on negative for the loop, so it would never loop.) But it apparently assembled fine with ca65. My point isn't that 64tass is better than ca65, but getting a bit philosophical I have found that some assemblers were build by people who "think like I do" and their behavior makes sense to me and catches things where I might have made a mistake. Other assemblers are fine, but their behavior might not be as intuitive. Should the two compliment representation of -8 assembler with an LDY instruction? ca65 makes the assumption it should. 64tass makes the assumption it shouldn't.

Is one right and one wrong? I don't think it is that clear.

My advice (and how I settled on 64tass) is to take some simple code like a "Hello world!" example and run it through a couple of assemblers. It might take you a few hours to test drive a half dozen. Then decide which one feels comfortable.

My two cents worth...

Thanks,
Jim W4JBM

[barrym95838]

Thank YOU, Jim. You and I appear to be on the same wavelength, but you stated our case much more eloquently than I did.

Mike B.

[jim30109]

One other thing I'll toss out because I've looked at it is that Western Design Center offers a no-cost version of their C compiler and assembler for non-commercial use with their chips. I believe the C compiler is ANSI C and the assembler sticks to the WDC recommended syntax.

I have downloaded it and was planning to try it. I got it installed but never used it.

I believe it integrates with the monitor found on the single board computers they offer. Something like their 65256 SBC offers a lot of stuff for not much money. (One cool feature if you are going to build is that it can turn one of the output ports into a set of chip select lines which can save you the trouble of having to implement the external logic to do that. For not much more than you would pay for the CPU, UART, RAM, and ROM ICs you get the whole package with tons of I/O.)

Thanks,
Jim W4JBM

[BigDumbDinosaur]

jim30109 wrote:

I believe the C compiler is ANSI C and the assembler sticks to the WDC recommended syntax.

However, the compiler doesn't seem get perturbed if you use K&R-style function prototypes (though not recommended). I learned C long before the ANSI standard existed so old habits have been known to creep in now and then. GCC usually emits a diagnostic if a K&R-style prototype is declared and that has made me try to adapt to that new-fangled thinking.

The assembler exactly implements the MOS Technology assembly language standard, along with some fairly common alternate mnemonics, e.g., BGE as a replacement for BCS, as well as the features needed to assemble native mode 65C816 code.

[Vladimir]

My apologies, I mislead you all. Really, all mentioned by me .BYTE directives do give an error. The attempt to assemble the EhBASIC gives 114 errors, but only the last 77 ones can be seen in console window.I thought I could see the whole assembler output, but, even if the scrollbar is at the top, the first lines of output are lost. I did not understand it at once and hurried to ask a question on the forum. My apologies once again.
Therefore, 114 directives (but not all) should be replaced by .text directives. It is necessary to somehow automate this process... Some .byte directives, containing bytes, are correct, for example .byte $80, $00

Thank you.
Vladimir

[Klaus2m5]

Vladimir wrote:

114 directives (but not all) should be replaced by .text directives. It is necessary to somehow automate this process... Some .byte directives, containing bytes, are correct, for example .byte $80, $00

.text $80, $00 should work. So why not replace all .byte with .text anyway?

[Vladimir]

There are such variations:
.byte $0D, $0A, "READY", $00
Should this work as .text ? If so, my life is simple, I can replace automatically
In short, it is not difficult for me to test this practically...

Thank you.

[Arlet]

Vladimir wrote:

There are such variations:
.byte $0D, $0A, "READY", $00
Thank you.

Some assemblers accept that as "\r\nREADY", 0

[jim30109]

I've replaced .byte with .text for things like .text "text",$0d, $0a,0 with no problems. But I have grown to like .null "text",$0d, $0a also.

[Vladimir]

For now, after the replacement, all is OK with '.BYTE' and '.TEXT' directives. There are only two lines with errors.

Code: Select all

435:11: error: not defined 'IRQ_vec'
Ibuffs = IRQ_vec+$14
435:11: note: searched in the global scope

1558:19: error: invalid operands to multiply '*' "address' and 'int'
	CMP	#[TK_TAB-$80]*2	; compare normalised token * 2 with TAB

Error messages:   2
Warning messages:  None
Passes:           2

I really could not find the definition of 'IRQ_vec'. About address multiplication, cannot figure out too...
Are there any opinions on this matter?

Thanks
Vladimir

[jim30109]

I'm not where I can read the manual, but I think it is taking * as the current address instead of as the multiplication sign. Maybe try adding it to itself instead of multiplying would fix it? I'm sure there is a more elegant solution but that's what comes to mind as a quick way.

Jim

[jim30109]

The IRQ issue is a bit deeper and not related to 64tass. They can provide more details in the EhBasic forum, but you need to implement some type of interrupt handler for EhBasic to work with. You can find a bare bone example in the Symon code for EhBasic.

Some would call it heresy, but if your focus is basic and you are building your own machine I would be tempted to set interrupts aside for a while. They are fairly straight forward, but just add another layer of complexity and potential issues. With BASIC they only add marginal value anyway.

Jim

[Vladimir]

jim30109 wrote:

I would be tempted to set interrupts aside for a while. They are fairly straight forward, but just add another layer of complexity and potential issues. With BASIC they only add marginal value anyway.

I'm not at all in a hurry with IRQ's. I need only the correct 'dummy' into the code instead the 'Ibuffs=IRQ_vec+$14'.
My priority order for external subroutines is as follows: OUTPUT, INPUT, LOAD, SAVE and (maybe) IRQ.
BTW, I replaced the square brackets with parentheses.

Code: Select all

CMP   #(TK_TAB-$80)*2   ; compare normalised token * 2 with TAB

The first error disappeared. Has it affected anything else, God knows.
What should mean square brackets there?

Edit: Some questions may disappear after careful examination of the file "min_mon.asm". At first I missed it.

[Vladimir]

I went through basic.asm searching for square brackets. Not considering comments, such brackets were discovered one time only, in the case under our consideration, i.e. CMP #[TK_TAB-$80]*2
What could this mean?
As for the IRQ, the question is removed. It seems, the main file to assemble is min_mon.asm
The basic.asm is involved into assembling through the .include directive. In this case there are no errors.
Thus, at the moment, there is only the 'square brackets' question left.
Vladimir