Talk:Intel 8080

message: I was recently told about the NEC V20, which had an 8080 compatible mode. Should it be mentioned in this article? --StuartBrady (Talk) 17:28, 17 April 2007 (UTC)
replies: text: Probably not. That was marketed much more as a drop-in replacement for the 8088. The 8080 mode was probably just a gimmicky "might as well include it" extra to make it an option for upgrading 8080 machines as well as 8088 ones (both chips used the same package, though with slightly different pinouts) and so increase sales. But by the time NEC's chip was on sale, the 8080 was pretty old news - the 8086/8088 was the new game in town, and anyone who'd wanted more power from their system would probably have installed an 8085 instead already. I've heard many examples of people upgrading PCs and Tandys with V20s, and even some OEMs installing them by default, but never a squeak about it being used in place of the 8080 (or 8085). 51.7.49.27 (talk) 19:00, 18 September 2018 (UTC)
thread_title:  [[NEC V20]] 

message: Is this true? The z80 is also officially documented as having 256 input/output ports, but always loads the entire 16-bit address bus according to the usual rules of 16-bit register pairing (e.g. "OUT (C), A" actually outputs A to the port BC) so actually supports 65536 input/output ports in all versions. As the 8080 also has a 16-bit bus, it has to get a high address byte from somewhere, is it anywhere deterministic? — 87.194.58.250 (talk) 22:53, 3 July 2008 (UTC)
replies: text: I belive the 8080, unlike the Z80, asserted both the lower and the upper part of the address bus with the same 8-bit I/O-address; have to check the data-sheet (have it somewhere) to be completely sure, however. HenkeB (talk) 17:52, 17 August 2008 (UTC)
thread_title:  "The 8080 supported up to 256 input/output (I/O) ports" 

message: The pin 17 is DBIN and not RD, Pin 21 is HLDA, WR is WR# (low active) and so on...
Look at: http://datasheets.chipdb.org/Intel/MCS-80/intel-8080.pdf - 77.20.250.82 (talk) 02:51, 14 November 2008 (UTC)
replies: text: Checked datasheets ( and ) and corrected article. I think this information (pin functions) is not needed in the article. See for analogy Intel_4004, Intel_4040, Intel_8008, Intel_8085 and Intel_8086.82.193.140.165 (talk) 07:07, 17 October 2016 (UTC)
thread_title:  Pins 

message: The 8080 implemented the "pre x86" ISA? The article should state what ISA it implements, not some broad generalization. Rilak (talk) 17:16, 21 November 2008 (UTC)
replies: text: Presumably the quasi standard shared by the 8080, 8085, and Z80. It was quite widespread in the S100-bus, generally CP/M-using first-generation micros of the mid 1970s. However, it would probably be a case of mistaken precedence to say that the i8080 "implemented" that standard architecture... rather more accurate to say it gave rise to it. S100 basically developed from a need to gang all the signals for an i8080 based multi-board computer (including all 40 of the CPU's external lines) through a commodity bus connector, which happened to be a mil-spec 100-conductor board-edge slot because that's what was most cheaply available. It wasn't anything Intel came up with, specified, or had in mind whilst designing the chip. The other two CPUs happen to use the same general pinout for convenience, and so saw widespread use in S100 designs that therefore needed little or no real modification (a few minor things like implementing the Z80's NMI were sometimes bothered with) to take advantage of their improved performance. However, it certainly wasn't an 8080/workalike exclusive backplane ISA - about a dozen different CPUs, including some with extremely different design philosophies and signal architectures (e.g. the Motorola 68000) were ultimately adapted to work with it. 51.7.49.27 (talk) 19:08, 18 September 2018 (UTC)
thread_title:  ISA 

message: It seems odd that there is no mention of the flag register.  Although it is not accessed with all the instructions that can be used with the other registers, including A, it is accessed with the A register in the  PUSH and POP instructions, ie,  PUSH AF  and POP AF. as if AF was a pair, like BC, DE and HL.
: That is odd, now that you mention it.  I've added a section. --Wtshymanski (talk) 15:55, 7 February 2013 (UTC)
replies: text: Checked datasheets ( and ) and corrected article.   82.193.140.165 (talk) 07:13, 17 October 2016 (UTC)
replies: text: The same mistake seems to have propagated to the articles Intel 8085 (where this bit was undocumented) and FLAGS register, now corrected. 31.46.199.69 (talk)  —Preceding undated comment added 14:38, 28 October 2016 (UTC)
thread_title:  Flag register 

message: The official documentation does not mention an Interrupt flag at bit position 5. In fact it claims that the PUSH PSW (PUSH AF on Z80) writes 0 on the stack at this bit position. The EI/DI instructions set and reset the INTE flip-flop, not an interrupt flag. If such a flag does exist, it is likely very obscure, and a reference would be needed.  — Preceding unsigned comment added by 31.46.199.69 (talk) 13:36, 10 September 2016 (UTC)
replies: text: Checked datasheets ( and ) and corrected article.   82.193.140.165 (talk) 07:13, 17 October 2016 (UTC)
replies: text: The same mistake seems to have propagated to the articles Intel 8085 (where this bit was undocumented) and FLAGS register, now corrected. 31.46.199.69 (talk)  —Preceding undated comment added 14:38, 28 October 2016 (UTC)
thread_title:  Interrupt flag 

message: Sample code for "memcpy" seems to re-enter the whole subroutine (the "loop" label is on top), including the initial (due) test on BC=0. I never programmed for the 8080, but I think repeating that test and returning if zero is basically useless after the first iteration. Ultimately, the "loop" label should bring the cpu back to the "ldax" instruction after the end-of-loop test (jnz) established that B (BC) hasn't (yet) reached zero. Correct me if I'm wrong, though.  — Preceding unsigned comment added by Alessandro Ghignola (talk • contribs) 21:23, 26 January 2017 (UTC)
thread_title:  Error in sample code? 

message: I've looked over the article, and the pinout, back and forth a couple of times, and I just can't figure it out. If the idea of the chip having a wholly discrete set of 256 (x2) 8-bit IO ports is to keep that traffic separate from local memory transactions ... how does it do that? There doesn't appear to be a completely separate IO bus akin the the modern QPI or PCIe (nowhere near enough pins anyway), but nor does there seem to be any way of asserting an external signal that would trigger the support logic into recognising the 8-bit address copied onto the two halves of the address bus specifically as an "I/O" one instead of a memory address and thus piping 8 bits of data to or from a peripheral instead of a matching RAM address.
If instead it's specifically that a duplicated 8-bit address on the 16-bit address bus somehow triggers it, well ... there's a whole long list of reasons I can think of for THAT being a really bad idea, that would be far worse than the typical alternative (such as used with the 8086) of corralling all the IO ports into the very top end of memory (IE, FF00 thru FFFF) and just having the trigger being "are all 8 MSBs set to 1?", and certainly no better than the alternative used e.g. on various 68000 machines where the CPU is supported by a memory manager chip that receives addresses and internally separates them into accesses to RAM, ROM, various I/O peripherals etc, which are themselves permanently attached to the data bus (and in a lot of cases the address bus as well) but only activated when the appropriate back-alley CS line running to them from the MMU goes high.
In all those cases you're still going to lose at least 256 bytes of memory space if not more (still, is that really such an issue when you've got another 63.75kb to play with?) and have to be careful not to accidentally overrun into IO space when writing/reading large blocks into/out of RAM (but in that case you'd end up "smashing the stack" first anyway, and on e.g. the 6800/6502 ultimately end up wrapping round into Zero Page and causing a monumental crash).
If you want to have the IO truly separate from memory, there needs to be some simple way to signal the support logic that the address being presented is either one of the 256 IO addresses, or one of the 65536 memory addresses (just a single "IO/MEM" line would suffice, with the active space being determined by whether the line is high or low; essentially, it's an "A16", for a memory architecture that has only 64.25kb available and reserves the top quarter kilobyte for memory-mapped IO), and as it stands there doesn't seem to be any method of doing so...?! 51.7.49.27 (talk) 19:49, 18 September 2018 (UTC)
replies: text: I believe Intel wanted another, smaller address space for I/O operations (but a bigger space than on the Intel 8008.) The IO status bit that you mentioned in the status word simplifies decoding the IO space. Without this status, if you wanted to carve out only the last 256 bytes of a 64K memory space for IO use, you would need an 8 input AND gate. Feature of marginal benefit: If the IO space is not explicitly decoded, IN and OUT instructions access memory. Because the IO port number is mirrored on the upper and lower address buses, memory locations 0000H, 0101H, 0202H...0FEFEH, 0FFFFH are accessible. RastaKins (talk) 00:56, 12 October 2021 (UTC)
replies: text: Yes it is inconvenient to need to decode them separately.  I believe some use memory mapped I/O with Intel processors.  I suspect it was usual for minicomputers at the time to have separate I/O space, which influenced the design.  Though, as well as I know, the 8080 wasn't intended as a minicomputer replacement, but instead an upgrade from the 8008.  People did try to make microcomputers (that is, general purpose programmable boxes) out of the 8008, but they didn't get very popular.  The 8080 really is where processors became powerful enough to do it. Gah4 (talk) 21:25, 19 September 2018 (UTC)
thread_title:  How the heck does I/O addressing work? 

message: The example code only works if the reader's screen is wide enough; otherwise, the comments wrap around, causing the machine code column to be out of synch with the asm code column. Anyone know how to fix? --jpgordon𝄢𝄆 𝄐𝄇  15:53, 3 March 2020 (UTC)
thread_title:  Example code format 

message: The article states that the a register is an 8 bit register, but the instruction set seems to contradict this. For example the instruction `ldax b` loads register pair `bc -> a`. That would require that a is 16 bits wide. Similarly, `stax b` does the opposite by loading `a -> bc` — Preceding unsigned comment added by Dakoolst (talk • contribs) 22:18, 12 April 2021 (UTC)
replies: text: Don't know where you're getting your instruction set info, so I can't remark on its presentation, but you're misunderstanding how those instructions work. LDAX B does an 8-bit load of A from memory using the 16-bit memory address in BC (one notation for this is (BC) -> A); similarly, STAX B does an 8-bit store of A to memory using the 16-bit memory address in BC (A -> (BC)). Each of those instructions uses the 16-bit register pair as a pointer to an 8-bit memory location. --Colin Douglas Howell (talk) 15:47, 14 April 2021 (UTC)
thread_title:  A register bitwidth