Search Results

Putting automatic objects on the stack is a horribly inefficient way of handling them on the 8080 and Z80 unless it is necessary to support recursion or reentrancy. … Copying the stack pointer to IX on function entry and then using IX to access automatic objects is somewhat reasonable from a code-size perspective, but the Z80's 4-bit ALU makes it very slow to process …

Both memory and I/O instructions that use C as part of an address output C on the lower part of the address bus and B on the upper part (which will often be ignored by the outside system, but is outpu …

A proper "start of instruction" indication would have been more convenient than the Z80's "some kind of opcode byte", but most code won't go very long without a write cycle, and once a write cycle occurs … Perhaps an ICE could track things even without M1, but it would require a more complicated state machine that understands almost all Z80 opcodes rather than just a few prefix bytes. …

A handy way of outputting a string on the Z80 is to use something like: primm: ex (sp),hl primmlp: ld a,(hl) call putchar inc hl ld a,(hl) or a jr nz,primmlp ex (sp),hl ret The message …

A major question to consider is whether it would be acceptable to tie up the Z80 during significant parts of each frame. … If one is willing to tolerate a severe amount of CPU loading, one could produce a Z80 video subsystem with a surprisingly small number of off-the-shelf parts. …

The normal way to handle cross-bank calls is to use a springboard which is either in an unbanked area of memory or appears identically in both old and new areas. If one doesn't mind using a different …

The most efficient way to process a C++ dialect on the 6502 or Z80 would probably be to design a virtual machine analogous to the UCSD P-system and then write a compiler that targets that. …

If the branch is skipped, the Z80 will skip those additional calculations. When processing a JP instruction, the Z80 fetches the next two bytes and increments the program counter while doing so. … Since the Z80 isn't performing any arithmetic with the target-address bytes, making use of them once they're fetched is no more expensive than discarding them. …

The purpose of NMI is to cause the Z80 to execute code located at the NMI handler. … The purpose of Bus Request is to prevent the Z80 from executing any code until whatever wanted the bus is done with it, but not affect the sequences of instructions and memory operations performed by Z80 …

If there are two consecutive bytes of RAM one can write at a known address, one could store the byte values E1h, E9h [POP HL / JP (HL)] at that address and then CALL it to place the address following …

. (*) Since writing the above, I've discovered that the Z80 uses a 4-bit ALU, and has steering logic to load/store its value from/two the upper or lower half of either half of any 16-bit register pair, …

Many operations on the 6502 take fewer cycles than corresponding operations on the Z80; the ratio tends to be somewhere between 2:1 and 4:1. … On the Z80, if the table is page-aligned, and if the address of "index" happens to be in HL--rather favorable assumptions--one may be able to get by with something like: ld d,tableH ld e,(HL) ld a,( …

The designers of the Z80 thought it would be useful for code to quickly determine whether signed arithmetic operations overflowed. … Have a "compatibility mode" flag which switches some instructions between perfect 8080 emulation and enhanced Z80 operation, along with instructions to turn it on and off. …

The Z80 increments the program counter while it is performing an opcode fetch. … As a consequence, by the time an opcode byte is fetched, the Z80 will be committed to completing the instruction before any interrupt may occur. …

While the Z80 is definitely an 8-bit processor rather than a 16-bit one, the instruction set makes some operations easier with 16-bit values than 8-bit values. …