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)


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 ?

  • 1
    Is the source it similar or is it the same? Is the assembler you're using the one the source is made for? Not all assemblers use the same syntax. Is there anything different right before these 5 definitions? Tried to change that? Tried to change sequence? Just the usual debugging questions...
    – Raffzahn
    May 5, 2021 at 9:19
  • Hi @Raffzahn, thanks. I also tried using exactly the same code. Again, up to 0x9FFF it assembles fine, and fails as soon as I specify 0xA000 on line 56. Same issue with both vasm and TASM.
    – Charles
    May 5, 2021 at 10:44
  • 6
    I suspect that both vasm and tasm gets confused by the 'A'. Tasm seems to think it is a label, and vasm seems to gets confused when it unravels "FPEXP .EQU FPREG+3" (the line before the errors). Diving into the manuals might find some explanations what is happening. For tasm I'd use 0A000H instead of A000H. The manual will tell you if this is correct or not.
    – UncleBod
    May 5, 2021 at 11:41

2 Answers 2


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:


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.)

  • 1
    Ironically, I had a different problem with the first Z80 assembler I ever used: I had a program to play the first two parts of Bach's Two Part Invention #13, and the assembler balked at the label I chose for the music data: Bach, since it interpreted it as equivalent to 0BACh.
    – supercat
    May 6, 2021 at 16:24

[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.

  • it's not ADA but Ada btw :) May 6, 2021 at 13:09
  • @Jean-FrançoisFabre good point. Try it, maybe you got enough rep to edit. P.S.:did you also find all other spelling issues?
    – Raffzahn
    May 6, 2021 at 13:31
  • 1
    still looking for them :) (I already edited a lot of your posts) May 6, 2021 at 14:05
  • 1
    @Jean-FrançoisFabre I know, and I'm always grateful for your help - I know I'm a bastard when it comes to spelling - no matter what language :)
    – Raffzahn
    May 6, 2021 at 14:26
  • 1
    @Jean-FrançoisFabre Oh, you're trying really hard. I like that. Give it to me :)) (SCNR)
    – Raffzahn
    May 6, 2021 at 14:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .