Cannot assemble BASIC with high memory workspace (Z80)

Question

This is a homebrew Z80 computer, using Z80, 64K RAM, EEPROM as well as SIO/0.

I am trying to run BASIC, however I need to set the workspace at 0xC000 or higher. The code I am using is similar to https://github.com/feilipu/NASCOM_BASIC_4.7/blob/master/rc2014_NascomBasic56k/bas56k.asm#L56

I can increase Workspace location upto 0x9FFF, however as soon as I set it to 0xA000 or higher assemblers start complaining about various issues.

vasm complains that it cannot find the last 5 variables (lines 112-116)

error 3007: undefined symbol <STLOOK>
error 3007: undefined symbol <PROGST>
error 3007: undefined symbol <MULVAL>
error 3007: undefined symbol <PBUFF>
error 3007: undefined symbol <SGNRES>

while TASM gives this error message

basic.asm line 0056: Forward reference in equate: (A000H)

followed by lots of

basic.asm line 0153: Unused data in MS byte of argument. (2)

messages.

What am I doing wrong here ? As if I am crossing a page boundary or something at 0xA000 but cannot figure out what the exact issue is. This is also completely independent of the address the basic code itself is running at.

How can I move the workspace beyond 0xC000 ?

Answer 1

Without reading the manuals it seems that both vasm and tasm decides if an operand is a number or a label is decided from the first character. A number MUST start with a digit in the decimal range, anything starting with a letter is considered a label. So you need to enter the number as '0A000H'.

So, when tasm finds an argument A000H it thinks it a label that is not defined and gives the error "Forward reference in equate:" Tasm is apparently a one pass assembler, so it just guesses it is a label that is defined later in the program.

The errors from vasm is not that clear to me, but my guess is that when vasm is unraveling the argument in:

FPEXP   .EQU    FPREG+3 

it loses track of where it is and apparently thinks the following lines are part of the expression in the argument. To explain why you need to examine how vasm is handling arguments and how it saves the values of the labels during parsing.

(A tip, if you get strange errors that aren't logical from a line or several lines in a row, the real error can often be found in the line before.This goes for most assemblers and compilers.)

Answer 2

[Uncle Bod's answer nails it. Vote for him. This is more of a background add on.]

The underlying issue is a hodgepodge of language and number mixup, further complicated by using a different notation when thinking about the problem (writing the question) as the one used within the code written.

In the question the OP asks about 0x9FFF vs. 0xA000, which is a specific way to note hex numbers in the C language. But the question is about Assembler, more specific an Intel-ish Z80 Assembler. Changing number systems between the work to be done and writing about is a real bad idea. It's kind of a programmers Engrish, like writing English using Kana. Sometimes dubious in a human environment, outright problematic when it's about the exact spelling a compiler wants.

Each language/compiler has it's own notation, where

• C wants 0xnnnn,
• Intel(ish) Assemblers want 0nnnnH,
• Motorola(ish) Assemblers like to see $nnnn, while
• IBM mainframes want a dedicated X'nnnn'.
• Some BASICs want &nnnn or &Hnnnn and
• Super variable languages like Ada or VHDL use radix based notations
• Plus many more

Seasoned readers may have noticed that I (try to) use hex notation the way the topic requires, not the way I prefer. When talking, well writing, about a language, it's important to use the notation inherent to that language. Using some other may in the best case has no effect, but, like shown here, may as well hide the issue one is looking for.

---

On a historical note Intel's 0nnnnH notation stems out of the same syntactical requirement as 0xnnnn for C. by having all numeric constants start with a decimal digit, the parser can quite easy distinguish between the next item found being a number or a name (label) - as labels are not allowed to start with a decimal digit.

---

Long story short: Assembler isn't just a more primitive version of C, but a different language. Like with every language it helps to not skip the first few pages of the manual, the ones where notation and basic syntax are explained.