The Z80 has an address space of 64KB. That means it can perform 8 bit reads or writes to 65,536 distinct locations as specified by the 16 address pins on the CPU. As far as the Z80 is concerned that's all it knows about.
Now it's up to the system designer to decide which of those locations lead to RAM, which lead to ROM, which might lead to memory mapped ...
The standard way would be adding it to HL. After clearing HL that is.
This is not only already available with the 8080,
DAD SP ; Same opcode (39h), same workings
thus preferable, but as well very handy when setting up a pointer to parameters on stack as, of course, any other constant than 0 can be used and added.
Foremost, there are direct continuations, CPU's able to execute 8080 code and (basically) hardware compatible, like the 8085, Intel's answer to the Z80, as it's mostly software and hardware compatible.
Beside Intel's direct extension, there is of course the series of enhancements of Z80 design, from Z800/Z280 all the way to the eZ80, which in some way can be ...
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....
A Z-80 program will be 15% smaller than an 8080 program.
To come up with this guess I took a reasonably tight Z-80 program, the TRS-80 4K Level 1 BASIC ROM and estimated the cost of replacing the Z-80 specific instructions with 8080 code. I'll get back to the limits of this methodology later but for now let me plow on with this example.
Of the 4096 ...
The old IDA freeware ver.3.7 supports Z80. It has a Turbo Vision style interface, which may be something that puts you off. It is also no longer distributed officially. However, it is very powerful, and if you can live with its quirks, you will be able to find it on many abandonware websites.
Alternatively, a lot of people started switching to NSA-developed ...
Simply because SRA C doesn't shift A by the content of C, but shifts C right by one with keeping bit 7 (sign) static.
Z80 and shifting:
While the Z80 did add some nice new shifts and rotates, like the mentioned Shift Left Arithmetic for all 7 registers and memory, it still only shifts by one bit position per execution. So any shift by more than one ...
Since it's two questions, here are two answers:
It's a very BASIC 65xx to x80 transition error: Index Registers
Where 65xx CPUs use a 16 it base address (from memory) and an 8 bit index (from register), the x80s use 16 bit index register(s) and an (optional) 8 bit offset. The address of msg should be loaded into IY first (LD IY,msg) and then ...
It's 64 KiB total in any combination imaginable.
Or more general:
The Z80 features
16 address lines (A15..A0),
sufficient to address 64 KiB (via D7..D0),
which can be used to access one of two address spaces
default memory (with next to all instructions, indicated by /MREQ) or
I/O locations (with IN and OUT instructions, indicated by /IORQ).
The problem with Z80ASM specifically is that it takes the assembly input and spits out a static binary file. This is good and bad.
In "normal" systems, address assignment is, inevitably, the responsibility of the linker, not the assembler. But assemblers are simple enough that many skip that aspect of the build cycle.
Since Z80ASM spits out literal ...
IM 0 is the backwards-compatibility mode with the i8080 CPU. You have to use some external circuit to provide desired RST 0..38h instruction. RST 0 is effectively the same as RESET, RST 38h is the same as IM 1 mode provides.
All the other RST addresses have their own meaning in the ZX Spectrum ROM (see):
RST 00h is RESET
RST 08h is ERROR
RST 10h is PRINT A ...
The 68000 does nothing; it is entirely disabled. Ditto the Yamaha OPN.
The Mega Drive's VDP is almost entirely backwards compatible with that of the Master System — it implements the graphics mode used by all but one of the Master System's games natively*. So there's no emulation or translation, it's just a different graphics mode.
Similarly the SN76489 is ...
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 ...
The CPU-CORE as described in the eZ80 User Manual (UM0077) does of course not reserve any I/O, but all real silicon eZ80 contain additional peripherals (*1), reserving the whole address range of 0080h..FFh for them.
See for example the eZ80190 Product Specification (PS0066) section Register Map on p.23:
All on-chip peripheral registers are accessed in the I/...
What is the canonical solution for this type of problem?
There isn't any canonical solution, but many variants, all to be found usable.
The only one that comes to my mind is to create a "jump table" at the beginning
Which is a perfect good one. Except, usually one would use jumps instead of calls to reduce code length, speed up execution, and ...
There were of course clones produced in the COMECON countries. Being clones, they would probably not make a good answer, with the exception of:
КР580ВМ80А was a Soviet clone that has been developed further into:
КР580ВМ1 with a frequency 5MHz needed just 5V and added some new commands, had support for bank switching and multiprocessor systems
The Z80 PIO is much more of an I/O co-processor than a classic I/O peripheral chip. For this reason, it needs to be connected to the system clock of the Z80 main CPU.
The PIO listens to various control bus signals like /RD /IOREQ /M1 and /RD and derives the intended or currently executed actions of the CPU from them (It does scan the data bus during the CPU ...
LD A, (IY+msg) looks fishy; on the Z80 IX and IY are 16-bit registers and the in-opcode offset is 8-bit. Sort of the opposite of absolute indexed addressing mode on the 6502. So you'd idiomatically load IY with the address of msg and then ld A,(IY+0). And if you're not using the offset, you might then consider (HL) instead for a more compact and faster ...
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 ...
but I can't find any explicit documentation.
The documentation for the Z80 behaviour is in its manual. For the way the CPC hardware handles it, you may need to see these circuits. It may, for example hold an IRQ until it is accepted.
but what happens in the case of the prefix? Is the interrupt acknowledged after the next instruction has been executed?
a) This is kind of borderline as it's about generic circuit design. Then again, it's about Z80 and I do see some RC.SE relevant insight that may come from comparing different solutions.
b) There are zillions of ways to do this and it depends on whatever main and side goals there are. The following is my personal take on this issue with an emphasis ...
According to this CPCTech entry:
In the CPC the Gate Array generates maskable interrupts, to do this it uses the HSYNC and VSYNC signals from the CRTC, a 6-bit internal counter and monitors the interrupt acknowledge from the Z80.
When [counter conditions are met] the Gate-Array will issue a interrupt request to the Z80, the interrupt request remains ...
Obviously what's compatible (or an advancement) to the Z80 also has to be compatible to the 8080.
That includes the Hitachi HD64180, the Zilog Z180 (which is essentially the same thing), the Toshiba 84013 and 015, and to a limited degree, the Toshiba TMP90 (which is only source-code-compatible to the Z80 but uses different opcodes). Rabbit Semiconductor is ...
Considering what I learned in the comments under the question, I'd suggest a combined hard/software solution to this design issue. It's based around a single port, or a consecutive group of ports that are handled as one, by all 'cards'. Decoding is done as sum of address and data.
Assumptions for all following:
Bit-numbering in Address/Data is LSB ...
[Since not closed by now, I'll try to give it a historic spin]
Hold Your Horses
In some way this is a case of second step before the first, or at least it seems like.
Thinking about how to swap segments, do caching or whatsoever is about implementation. There are many ways to do so, not at least shown by various home computers. But I belive this would fall ...
llvm-mos compiles a considerable subset of C++ to 6502 machine code out of the box. IIRC it's just missing "runtime support"; things like RTTI, exceptions, and the runtime layout of VTables. The last one is kinda important, but I don't think it's too likely that there are any compiler changes necessary to get that working; just "standard ...
The code could look like this:
0000 06 0F LD b,$0f ; 0-31 X
0002 0E 08 LD c,$08 ; 0-191 Y
0004 CD 0A 00 CALL convert_xy
0007 36 FF LD (hl),$ff ; write the pixels
0009 76 HALT
000A convert_xy: ; convert (x,y) in BC to memory address in HL
The JR instructions are slow when the branch is taken because they use a four-bit(!) ALU to compute the new address. This calculation can't start until after the target address is fetched (which it always will be). If the branch is skipped, the Z80 will skip those additional calculations.
When processing a JP instruction, the Z80 fetches the next two bytes ...
The org directive should do specifically what you ask. However, z80asm is a little simplistic in its output format. Instead you can use ds to place routines at particular addresses:
This will always put printc at 0x1000 and readc at 0x1100. There ...