[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 ...
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 ...
I see some issues, but since this is an assignment, I shouldn't provide a complete solid answer right away. However:
There are many Z80 variants out there. You may want to know exactly which chip is being used. Personally, I would tend towards using HCT-series logic there if you need TTL compatibility. However, I believe the I/O may be CMOS.
Look at the ...
Comments have already covered that the CPU manual should answer all your questions, but above and beyond that, immediate observations:
ld (nn), bc is encoded as ed43 so that's two reads;
the actual address, 0x1000 is also two bytes long, so that's another two reads;
bc is two bytes long, so that must be two writes.
In total that's six memory accesses, from ...
The various issues are due clocking. In part by using 'unconventional' ways of clock handling but as well by simply violating specs.
Main points are
SIO (and in fact CPU) are not static designs but dynamic. As such they requite certain clock speeds and relation.
Clocking the system at 10 Hz violates a whole bunch of rules
Minimum system clock speed ...
Sure, a lot can be done. Source code translation always offers the possibility to replace one instruction by a sequence - like Intel already did for a few. This would as well solve the issue of incompatible hardware, like simply exchanging all registers with a copy in memory when the alternate register set is selected.
Just, who should do this?
Intel had ...
I'm going to say "No" simply because the 8086 doesn't support the alternate registers of the Z80. That was a fairly important concept that you can not directly mimic on the 8086.
Mind, if you're willing to dedicate memory and whatnot to support it, then, "sure". Replace the Z80 functionality with a macro, say. But now you're stretching it....