Old 8080/8085 support chips?

xanatos

I've got a few old chips that I *think* are support chips for the old 8080 or 8085 chips, but I can't seem to find much about them. All the google results are those "parts locator" houses that pick up any part number ever searched and say they can get it in 24 hours...

They are:

1NS8154N RAM I/O, radio shack p/n 276-2511
1NS8212N 8 Bit I/O Port, radio shack p/n 276-2512
1NS8224N Clock Generator, radio shack p/n 276-2524

Does anyone know and/or want these? I bought them in a HUGE load of electronics stuff I got at a tag sale least week. You wouldn't believe the haul I took in!

Thanks for the info,

Dave

Heater.

They are Nat Sem devices "INS" not "1NS"

Intel 8224 http://matthieu.benoit.free.fr/cross/data_sheets/D8224.pdf


Intel 8212 http://pdf.datasheetcatalog.com/datasheet/Intel/mXyzzqsw.pdf
Not recommended for new designs

Nat. Sem. INS8154 http://pdf1.alldatasheet.com/datasheet-pdf/view/115632/NSC/INS8154.html

whicker

Aren't these parts from about the time IBM was trying to obfuscate the PC, to make it hard to clone?

Anyways, instead of searching for that exact string, search for "8154 datasheet" or "NS8154 datasheet" or "National Semiconductor 8154 datasheet"

I personally don't have a need for these.

xanatos

Heater, you rock! Thanks.

I was looking at the printing on the Radio Shack bubble-pack thing - these are new & unopened! It definitely is a 1 on there, but closer inspection of the chip looking through the old yellowed plastic does show an I

So they are definitely for the 8080A crowd...

Thanks again.

Heater.

Whicker,

No, these are older than that. The 8 bit era. A real treasure trove. Now if you had some 8085 to go with them you'd have a computer almost.

trooks

Heater. wrote: »

Whicker,

No, these are older than that. The 8 bit era. A real treasure trove. Now if you had some 8085 to go with them you'd have a computer almost.

Gosh.

Havn't seen or heard of these since I did mods to my Trash 80.

It went missing in my second divorce.

xanatos

Well, if any 8080A fans are on here, it's now on eBay .... http://www.ebay.com/itm/251594195755?ssPageName=STRK:MESELX:IT&_trksid=p3984.m1558.l2649

Dave

localroger

There is a bit of confusion around. The OP's chips apply only to the 8080, not the 8085 which came later with simplified busses or the Z80 which came later with a lot more power and simplified busses. There weren't a lot of early PC's with the 8080 because it required expensive support chips compared to, for example, the 6502. My computer had one because it was a surplus job that failed in the marketplace.

Heater.

Quite so localroger. although I think it is only the 8224 clock chip that is 8080 specific here.

The 8080 was a hassle partly due to it's need of a -5v and 12v power supply as well as +5v. Also it needed a 2 phase clock input. We really are getting back to the dawn of time here.

kwinn

Only the 8224 is 8080 specific. The other 2 were used by multiple 8 bitters at the time.

Gadgetman

When Intel went from the 8080 to the 8085, they wanted to integrate a number of functions, especially an UART, which required external pins.
for that reason they multiplexed the Address/Data bus(the lower Byte of the Address bus is also the Data bus). That freed up 7 pins. (Had to add a 'latch' signal )
Unfortunately, it also made it 'waste' a clock pulse for every memory read/write operation.

One of the design issues that made some designers quit Intel and form Zilog instead.
Their design, the Z80 tossed out the UART and multiplexed bus.
Then they doubled the number of available registers, which makes it possible to build very fast interrupt routines, which meant that serial could still be done 'pretty fast' without sacrificing overall performance.

The problem with the Z80 is that almost no one really understood how to actually get the most out of the 'speicalised' instructions in it. Or even worse, they used compilers and assemblers written for the 8080/8085 chips.
(I like to take a 'peek' at the internals of old computers, and also happen to have a EPROM burner, which can also be used to read out the contents of said chips... )
Very few systems actually use the alternate registers at all, instead relying on PUSH/POP. Block COPY/COMPARE ? yeah, right...
(I know that some actually uses the block READ/WRITE IO commands, though.)
I've never seen the extended interrupt system in use.
(In short, in one mode, the Z80 will wait for the interrupting device to load a Byte on the Data bus, and use that Byte in a table to find where in ROM the correct interrupt routine is stored)

The 6502 and its descendants are simple... and when running in 'Page Zero' mode, it is actually pretty fast. The problem is that page Zero is of course only 256Bytes.
(The Z80 does 'Jump Relative' instead, which also only uses a single Byte as address, shaving off another 4 clock pulses off of the time a normal JUMP would take. But as it works relative to current address, the 'Block' it works in is kind of 'sliding along' )

Hm... May need to add a 6502 SBC to the collection soon...

Heater.

That's a good summary of the 8080/8085/Z80.

I have not really looked into this but I have heard that whilst all those hundreds of extra instructions may be convenient for programmers to write with in assembler they did not actually produce much in the way of a performance increase. One would have to look at the clocks required for such instructions and compare to equivalent 8080 style code sequences.

Similarly the alternate register set is probably a speed up if your interrupt routines are really short. For longer interrupt handlers the overhead of pushing and popping some registers becomes insignificant.

Compilers in general on any architecture never make use of such esoteric instructions. Adding optimizations to do that was probably too hard and it would make the compiler not fit in the memory space of, say, CP/M systems. Besides compiler vendors had to support 8080 for backwards compatibility and perhaps they just stoped thinking about 8 bit machines as the 16 bit era was coming.

Leor Zolman creator of the famous BDSC 8080 compiler for CP/M is a member of this forum, it would be great if he noticed this and could comment on Z80 compiler issues. As far as I remember he did use the Z80 block instructions in the string handling functions of the C library.

Gadgetman

Strange thing is, though, that I have found the 'undocumented' Z80 instructions used...
(Can't remember which machine, though)

The EXX instruction takes 4 clock cycles, or a total of 8 for a pair of them to replace the BC, DE, and HL registers with the alternates and back again.
That same job with PUSH, then POP would take 66 clock cycles. Doing the AF registers would add another 8clocks with EX AF,AF' versus the PUSH/POP's 22 clocks.
88 or 8 cycles?
The difference is only 20uS...
(at 4MHz)
Not much, unless you want to implement an interrupt-driven 'housekeeping' routine that needs to fire off 10 or 100 times/second.
Maybe you're trying to play a soundtrack in a game...
Or you're trying to implement a decent UART, or possibly using the Z80 as the HDD-controller in a mainframe computer...
(Reminds me that I haven't yet checked the ROMs of the disk controller from the ND5700 mainframe I have stashed away.)

It's not how long the routine is that hurts, but how often it runs.

16bit was the beginning of bloat.

trooks

Heater. wrote: »

Quite so localroger. although I think it is only the 8224 clock chip that is 8080 specific here.

The 8080 was a hassle partly due to it's need of a -5v and 12v power supply as well as +5v. Also it needed a 2 phase clock input. We really are getting back to the dawn of time here.

Oh No!

I feel sooo old.

Some that were geeks before geeks was a word fought hard for the V7. Whatever happened to the V7 I wonder?

Heater.

trooks,

"V7"? The what?

Before we were "geeks" and "nerds" we were "boffins", "back room boys". Can't remember what else.

Heater.

Gadgetman,

It's not how long the routine is that hurts, but how often it runs.

Well sort of, some times. Clearly the average CPU load created by an interrupt is it's run time multiplied by it's frequency. But that is not all there is to it.

Interrupts are many and varied complex things.

There is latency to think about. You might have an external event that needs acknowledging within a handful of instructions. In that case swapping register sets on interrupt might just save you the time you need over pushing registers to the stack.

You only get that fine grained latency if you are the highest priority interrupt in the system. Other interrupts will get all kind of jitters depending in what the higher priority stuff is doing.

Or latency might not be such an issue. Say for an interrupt hanging off a 100ms timer tick. In that case swapping regs may not be needed.

If such a timer tick, or other, interrupt is quite long winded then saving those push/pop cycles becomes a very small percentage of the whole thing and not worth worrying about.

In my first paying job I worked on a control system based on 8085 that controlled and monitored a machine rotating at 5000 rpm and creating product at 10000 per minute. Each of which had to weighed and inspected in real time. As well as monitoring machine function and safety. We did not feel the need for a Z80 there, it would not have helped noticeably. For the improvements we wanted to make a lot more horse power would have been required.

All in all, this kind of hassle with interrupts makes you really appreciate the Propeller:)

kwinn

@Gadgetman

The Z80 special instructions, alternate registers, and vectored interrupt hardware may not have been used much in general software but I did see it used quite often in some of the instruments I worked on. Those equipment designers were very creative when pushing the limits of the chip. Reminiscent of the creativity I have seen on these forums.

A multi-detector gamma counter used the block move instructions to address an additional 14K of memory beyond the regular 64K address space as an I/O buffer. Very little additional hardware beyond the memory chips was required, and it sped up sample processing and printing quite a bit.

A multi channel pulse height analyzer stored incoming pulse height data at much higher speeds than would have been possible without the alternate registers and vectored interrupt hardware.