Why the Z-80's Data Pins Are Scrambled 167
An anonymous reader writes "The Z-80 microprocessor has been around since 1976, and it was used in many computers at the beginning of the PC revolution. (For example, the TRS-80, Commodore 128, and ZX Spectrum.) Ken Shirriff has been working on reverse engineering the Z-80, and one of the things he noticed is that the data pins coming out of the chip are in seemingly random order: 4, 3, 5, 6, 2, 7, 0, 1. (And a +5V pin is stuck in the middle.) After careful study, he's come up with an explanation for this seemingly odd design. "The motivation behind splitting the data bus is to allow the chip to perform activities in parallel. For instance an instruction can be read from the data pins into the instruction logic at the same time that data is being copied between the ALU and registers.
[B]ecause the Z-80 splits the data bus into multiple segments, only four data lines run to the lower right corner of the chip. And because the Z-80 was very tight for space, running additional lines would be undesirable. Next, the BIT instructions use instruction bits 3, 4, and 5 to select a particular bit. This was motivated by the instruction structure the Z-80 inherited from the 8080. Finally, the Z-80's ALU requires direct access to instruction bits 3, 4, and 5 to select the particular data bit. Putting these factors together, data pins 3, 4, and 5 are constrained to be in the lower right corner of the chip next to the ALU. This forces the data pins to be out of sequence, and that's why the Z-80 has out-of-order data pins."
[B]ecause the Z-80 splits the data bus into multiple segments, only four data lines run to the lower right corner of the chip. And because the Z-80 was very tight for space, running additional lines would be undesirable. Next, the BIT instructions use instruction bits 3, 4, and 5 to select a particular bit. This was motivated by the instruction structure the Z-80 inherited from the 8080. Finally, the Z-80's ALU requires direct access to instruction bits 3, 4, and 5 to select the particular data bit. Putting these factors together, data pins 3, 4, and 5 are constrained to be in the lower right corner of the chip next to the ALU. This forces the data pins to be out of sequence, and that's why the Z-80 has out-of-order data pins."
C=128 (Score:5, Informative)
There was a Z-80 in the C=128 , but it wasn't used.
There was virtually no CPM software adapted to the C=128
Typically 128s mostly were used in C=64 mode
Re:C=128 (Score:5, Interesting)
Yes, I found this part of the article amusing too.
C128s were cobbled together from too many different parts. And they appeared when the 8-bit generation was already on its way out.
However, the C128 mode had its uses. The BASIC was had lots of additional features (commands for music, graphics, sprites), and it had a built-in sprite editor. If you didn't know the C64 inside out and could do these things in assembly (blindfolded), the C128 mode gave you much more access to the machines capabilites. Too bad no company ever came up with a killer 8-bit machine. Z80 CPU, more than 64 kB RAM, sound and graphics like SID and VIC-II.
Comment removed (Score:5, Informative)
Re:C=128 (Score:5, Informative)
Too bad no company ever came up with a killer 8-bit machine. Z80 CPU, more than 64 kB RAM, sound and graphics like SID and VIC-II.
Really? Ever heard of MSX? See: http://en.wikipedia.org/wiki/M... [wikipedia.org] It came with graphics, sprites (TMS9918/9929) and was a standard design carried by several manufacturers.
Ah, MSX... weirdest computers in history. The Yamaha MSX computer was an awesome music computer with built in FM synthesis, and then you had the vastly different Spectravideo MSX, it was fully compliant with the MSX standard...but it's just that, not everyone was compliant - every MSX computer seemed to be a special variant of itself, something that confused me something so fierce back in the days, I even had a Memotech MSX, weird WEIRD computer.
:)
The games on the MSX computers wasn't mind blowing, nowhere near the commodore 64 games, it simply lacked the awesome sound capabilities of the 64. They had a wider color range though.
I remember the war between us Commodore users (65xx type processors) vs the Z80 series, yes - the Z80 was a far superior processor in many ways and sometimes I wished we had that processor just for the extended registers alone, not to mention that the speed was 4 mhz instead of our meager 0.97mhz (could be doubled if you turned off the screen). But the hardware sprites & scrolling is what beat the living bejeezus outta the other competing products.
And I nearly cried snot when the Commodore 65 didn't make it. It was a super-cool Commodore 64 with beefed up hardware, higher resolution, stereo SID sound (6 channels!) of pure ring-modulated goodness.
Ah, I'll go stare at my stash of Z0840004PSC, 27xxxx's and the rest of the Chip Pron in my vast land of NOS components...aaaahh..
Re: C=128 (Score:2, Informative)
Actually Z-80 vs 65xx is still a valid debate. The 65xx was much more capable at lower clocks. A good example being the "Woz Machine" floppy controller compared with many Z-80 boxes needing a second 6mhz Z-80 to run their floppy drives.
Re:C=128 (Score:4, Informative)
6502 to Z80 work per clock ratio (Score:3)
Speed of Z80 at 4Mhz was comparable to that of 65xx at 1Mhz
I thought the work per clock ratio between 6502 and Z80 was closer to 2:1, not 4:1. This would put, say, a 1.8 MHz Atari 800 and a 3.5 MHz Spectrum together, or a 1.8 MHz NES and a 3.6 MHz Master System. Where do you get 4:1?
Re: (Score:2, Informative)
I don't know about the 6502, but the Z80 takes 4 clockticks per (basic) instruction. IOW, it's a bit below 1 MIPS at 3.57MHz. The later R800, used in the MSX turbo-R, ran at 7MHz at took 1 clocktick per instruction, which gave it the "28MHz Z80 speed" it was sometimes quoted.
Re:6502 to Z80 work per clock ratio (Score:4, Informative)
Re: (Score:2)
The 6502 memory access style with the unified map worked well for tickling the registers on coprocessors and on bitmaps; very fast and predictable for display timing. The Z80 bus method was abstracted some although still quite useful.
Regardless, they are such simple devices there's no excuse not to master them both for maximum pleasure.
Re: (Score:2)
The 6502 had special addressing modes for accessing the bottom 256 bytes of memory. Addresses in both the 6502 and Z80 were 16 bit, thus taking two read cycles to get a whole address into the CPU so that you could then get the content at the address. However, with the 6502, "zero page" addresses could be read in one read cycle. Not only that, but pairs of zero page locations could be used for indirect addressing. They could be treated as a set of (slow) address registers.
When I first came actress the Z
Re: (Score:2)
Re: (Score:3)
Some Z80 instructions could take far more than 20 cycles, such as LDIR (which copied an arbitrary amount of memory from one arbitrary place to another). Most of them were 4 clocks for the first byte and 3 for each succeeding memory access. The Z80 had some additional capabilities that were wedged into the 8080 instruction set, and required long instructions. When I was building the fastest 64-bit multiply I could, I didn't use the index registers (IX, IY), since I could always get better performance wit
Re:C=128 + 6502 cost. (Score:2, Informative)
Also cost was a huge factor - the 6502 was significantly less expensive than the Z80s at the time.
And the 6502 gracefully entered the 16 bit field with 100% backward compatibility in the 65C816.
Sadly, too late to make a big dent as the 68000 was just around the corner, although Nintendo took
great advantage of it in their SNES. Franklin Electronic Publishers used the 6502 exclusively in
their early hand-held spell checkers.
Re:C=128 (Score:4, Informative)
The 6502 may have run at a little under 1MHz, but it was efficient. Most instructions were one or two cycles and they did a lot. It's actually a really fun processor to write for because it's both a nice architecture and very challenging to get the most from.
Re: (Score:3)
The problem with the 6502 was that if you were writing code for someone else's environment then your use of Page 0 (which many of the index-based instructions used intensively) was restricted because the OS often took up most of that space.
If you were writing code that was totally stand-alone (ie: no bios or OS to worry about) then the 6502 environment was *very* nice and could perform incredibly well. However, if you were writing code that sat atop a BIOS/OS layer then the Z80 was just so much simpler and
Re: (Score:3)
The problem with the 6502 was that if you were writing code for someone else's environment then your use of Page 0 (which many of the index-based instructions used intensively) was restricted because the OS often took up most of that space.
Yes, there was a mindset problem when programming the 6502. In hindsight, page 0 RAM should have been treated as a working space register set, whereas at the time it was treated mostly as a fast RAM littered with persistent variables.
Re: (Score:2)
In later models, i.e. well after the 6502 was obsolete for general purpose computers, there was an 8 register that you could set to change which page was regarded as zero page. If that had been available from the start, it would have saved me a lot of time looking for locations that didn't zap the MS Basic interpreter on our Commodore PET. I seem to remember that the floating point accumulators were considered the best bet.
Re:C=128 (Score:4, Informative)
Most Z80 code was written to be compatible with the 8080. As a result, the second register set wasn't used. Floating point math using the second register set for temporary variables made possible a substantial speedup.
If the 6502 and Z80 waveforms for various instructions are examined, it quickly becomes apparent that the Z80 effectively divided its clock by 2 before using it. This is why, for the technology available in any particular year, they had comparable performance but the Z80 used twice as many clock cycles.
The 6502 was a tremendously clever design for making effective use of a small number of transistors. The Z80, striving to be a superset of the 8080, was also a clever and powerful design for its time.
Re: (Score:2)
Actually, the problem was the ALU of the Z-80 was only 4 bits wide [righto.com]. So processing an 8 bit operand required two trips through the ALU, thus incurring twice the number of clocks or half the effective clock rat
Re: (Score:2)
Z80:
8 bit register adds, 4 clocks (equivalent to 2 6502 clocks)
16 bit register adds, 11 clocks, with carry, 15 clocks.
The slowest instructions (23 clocks) are obscure instructions like swap register with memory, or indirect indexed addressing. These were limited by the number of memory accesses needed.
I've built hardware and done a lot of assembly level programming on both the Z80 and 6502. There is simply no substantial speed difference between them for the level of technology available in any particula
Re: (Score:2)
MSX (Score:2)
In 1983, the 68k had been out for a few years already and new 8-bit computer designs were doomed.
Re:C=128 (Score:5, Informative)
And then Commodore went on to (half inherit, half design) the Amiga. Maybe "cobbled together" is too harsh for it, but still. Floppy controller that can decide, per track, whether to work in MFM or RLL (but not read a single sector, mind you), more DMA channels than the CPU can handle, and a display processor with a built-in three commands machine language (one of which was only ever used by one application ever) to change display resolution mid-monitor.
I loved it, but the Amiga gave the impression that it was designed by engineers that couldn't make up their mind on what choice to make, so they created hardware that would offload all decisions to software.
One last anecdote. Many have heard of the famous "Guru meditation". What only Amiga users know is that you knew one was coming because the power led would blink three times. Yes, the power led was software controlled, making the Amiga the first ever computer that could play dead.
Shachar
Re:C=128 (Score:4, Informative)
What only Amiga users know is that the only way the power led can be controlled is by enabling/disabling the low-pass filter on the audio output since the status of the enable signal is indicated by dimming the led. It's not possible to turn it off completely to simulate the computer being dead.
It's controlled by bit 1 of ciaa->pra. (Address $BFE001)
It's also possible to read a single sector, but that would require starting the DMA on a timer so it's more cumbersome than reading the entire track and it's not guaranteed to be faster since it's a spinning media. The memory is there so reading a single sector is just pointless. As for MFM/RLL encoding the floppy controller does neither, it reads the raw bits. The order of the bits is interleaved on Amiga formatted disks to allow for blitter accelerated MFM-(de)coding.
Don't trust anecdotes, the developer guides are available online.
Re: (Score:2)
What only Amiga users know is that the only way the power led can be controlled is by enabling/disabling the low-pass filter on the audio output since the status of the enable signal is indicated by dimming the led. It's not possible to turn it off completely to simulate the computer being dead.
The original Amiga 500, including the early Kickstart 1.3 ones, would actually completely turn off the LED. If you don't believe me, you are welcome to visit me. I still have my original machine in (more or less) working order.
You are correct that later models would not turn it off completely, but rather only dim it. I only remembered that fact after I hit Send, and thought no one will be anal enough to demand a clarification.
It's also possible to read a single sector, but that would require starting the DMA on a timer so it's more cumbersome than reading the entire track and it's not guaranteed to be faster since it's a spinning media.
In other words, the hardware does not support it.
As for MFM/RLL encoding the floppy controller does neither, it reads the raw bits. The order of the bits is interleaved on Amiga formatted disks to allow for blitter accelerated MFM-(de)coding.
That is one point I am not as sur
Re: (Score:2)
You can keep your ancient 1.3 books. I have the shining new 2.04 manuals in one of my unpacked boxes here (or maybe it is in storage, next to my actual Amiga?)
Shachar
Re: (Score:2)
built-in three commands machine language (one of which was only ever used by one application ever) to change display resolution mid-monitor
I'm curious... any more detail on this?
Re: (Score:2)
If I remember correctly changing display modes mid scan was often done so that workbench could do things like display HAM images in windows.
I think the OP may be talking about the "copper" which was a FSM with three states (MOVE, WAIT and SKIP) and a list of instructions to be processed when screen timing events occur. All three were used though and it was used for many things such as sprites and the above mentioned screen mode changes.
MOVE (put data in pretty much any register such as changing the location
Re: (Score:2)
If I remember correctly changing display modes mid scan was often done so that workbench could do things like display HAM images in windows.
You misremember. The Copper code to change display modes took several scan-lines to run. Having a window with different display mode was impossible. You could, and did, have a UI construct called a "screen", which had its own display mode. You could drag a screen down and see another screen behind it.
All three were used though and it was used for many things such as sprites and the above mentioned screen mode changes.
AFAIK, none of those utilized SKIP. They were all based on WAIT and MOVE. If you know differently, please provide further details.
Maybe I missunderstood the OP?
I don't think so. I am, however, fairly sure you mis-remember.
Shachar
Re: (Score:2)
SKIP does seem a bit limited if it is only one entry that it skips.
I think you either overran the time to execte so events had already occured or you finished early and waited for the next frame/whatever.
So how did workbench give provide windows containing HAM8 images or where they only full screen windows with a menu bar? (too long ago and I do not remember). I was using PC's back then but I was most impressed with a flatmates Amiga. Shame it struggled to run Elite :)
Re: (Score:2)
Menus on the Amiga were bound to the screen, not the window. You are probably remembering a full-window.
Shachar
Re: (Score:2)
You got a partial answer. If "SKIP" was ever used, I'm interested to know by whom. I only know of a single example, which was EXTREMELY special case.
The commands:
MOVE: move immediate value into copper register. These included such actions as where in memory the video memory was (i.e. - where to fetch the picture from), what is the palette, video resolution, where on screen the video fetch starts and where it ends and many others.
WAIT: wait for the screen update to reach a certain point. There was a mask arg
Re: (Score:2)
Amstrad CPC6128 was very successful, especially popular in Europe - cheap price as a dedicated monitor was always bundled and a floppy drive was integrated, whereas other stuff like C64, Spectrum etc. tended to be used with a cassette drive and on the television.
It's not a killer machine, though. Rudimentary sound and no sprites - but it was colorful, with 16 colors out of a 32 color palette (much better than 8 fixed colors on some of the 8bit crap :p)
Then it did have an upgrade that made it a "killer 8-bit
Re: (Score:2)
Re:C=128 (Score:5, Interesting)
Why didn't they just ask Federico Faggin? (Score:5, Insightful)
Why didn't they just ask Federico Faggin? According to Wikipedia, he's still alive.
Re:Why didn't they just ask Federico Faggin? (Score:4, Interesting)
This is what I came in here to say. They guy who designed the chip is still alive. Just shoot him a email, phone call, or smoke signals and just ask him.
I'm going to go out on a limb here and say there is probably a logical reason behind the arrangement and not some conspiracy or something.
Re: (Score:3)
Re: (Score:2)
The Z80 is still manufactured in classic form. It may be considered a trade secret and Faggin might not be at liberty to divulge anything about the inner workings of the chip without you signing an NDA.
Re: (Score:2, Informative)
Not only is it still manufactured, but it is still used. There is a good probability that your DVD burner has a Z80 in it running the show.
The Z80 is a great example of a 'limited' CISC design (not enough transistors to be complete CISC like say a Motorola 68000 or a DEC NVAX).
The 6502 is a great example of a 'limited' RISC design, and quite an efficient one. http://www.visual6502.org is still out there, and you can enjoy that yourself. I'm looking forward to the Z80 version, myself.
And you can build you
Re: (Score:2)
Re: (Score:2)
If you had read the article you would know that it is part of an effort to deconstruct the Z80 using optical information and yes they can see all the transistors although identifying them and thier function can be tricky as they were layed out by hand to minimise the space needed.
I have no connection to the project but reading some of the pages on the site are quite interesting if you are electronics minded.
Re: (Score:2)
Why didn't they just ask Federico Faggin? According to Wikipedia, he's still alive.
Maybe its time for:
Interviews: Federico Faggin [wikipedia.org] Answers Your Questions .... father of Intel's 4004 [slashdot.org] 43 years ago...
Last week you had the chance to pose questions to Federico Faggin
The man is very accomplished and has an amazing history.
Mysteries of the past (Score:2, Funny)
When I grow up I also want to be an archaelogist.
Why is it necessary to reverse engineer this? (Score:3, Insightful)
The Z-80 was a great chip and overall system design supported by very capable support peripheral chips in that family. The best part of working with it, is Zilog's Documentation, which was very well written and demonstrated the consistency of the entire product line (in terms of it's functional programming interfaces). There really is not any need to 'reverse engineer' the chip, everything you need to know is freely available already. I think this article and author means to say "Here are some plausible possible reasons behind some of these physical implementation decisions...".
I think all first year computer science / programming / engineering students should be introduced to this and learn how to write programs for this environment first before moving on to modern systems. True power is being able to write useful stuff with only 64kb of ram and 1mhz of processor, and have it run in an acceptable time frame, and taking those skills and scaling up today's multi-core/ multi-gigahertz/multi-gigabyte address spaces.
Why is it necessary to reverse engineer this? (Score:2)
I think all first year computer science / programming / engineering students should be introduced to this and learn how to write programs for this environment first before moving on to modern systems. True power is being able to write useful stuff with only 64kb of ram and 1mhz of processor, and have it run in an acceptable time frame, and taking those skills and scaling up today's multi-core/ multi-gigahertz/multi-gigabyte address spaces.
While I agree, I wonder if this is actually true. To what extend does
Re: (Score:2)
I think it may be somewhat daunting for a first-year student to go through the learning curve of what would effectively be debugging and optimizing code for an embedded platform... But it needs to be threaded in every CS course how to write code that is appropriate for the given application: speed/code/memory trade-offs and how to avoid code that blocks inappropriately, how to write programs that correctly work with the OS in terms of yielding, using timers, and such. Also, just calling the math library r
Re: (Score:2)
For all others it might not matter so much how the compiler and the OS handle memory allocations and the like, and it may be more useful to focus on the program structure instead of the implementation on the CPU.
With a cache miss costing 200 cycles (more or less) and a trip to L2 being more expensive than computing a square root, our choices with regard to memory layout are possibly MORE crucial now to getting decent economy and performance out of the machines we have today.
Re: (Score:2)
With programs generally being much much larger many such optimisations can just be lost in the noise. In some domains it is still useful but even more difficult than it was in times gone by.
Pipelining/OOE/register renaming and the multitude of processors with the same IS but remarkably different implementations, cache sizes/associativity/memory, memory size and connectivity
How many cores per CPU and how do they share those caches and memory buses.
How many independent memory banks per processor/chip (can cha
Re: (Score:2)
Older systems and complexity theory might favor the list, but the vector beat it badly on modern hardware simply because the h
Re: (Score:2)
I am not disagreeing with you but some of the things I pointed out above are varibles with respect to harware and most of them DO affect memory locality. If you make an assmption that x parts of data are localy cached you can be truely wrong when run on a compatable chip with a different cache layout or even the same chip but with a different offset that is only partialy aligned with the cache.
Some algorithms in general tend to keep the data used close to gether and they may benifit. Some algorihms uses dat
Re: (Score:2)
Re: (Score:2)
When your data and or instructions are not aligned on cache boundries and/or not limited by them (4k seems pretty standard for x86 and x64 3rd level caches but the processor may have different ideas about how that is segmented for L2 and L1) then you can cause cache thrashing by trying to tune for those specific variables. (your can cause the same by not tuning for them)
You say that it is remarkable how uniform current platforms are? I am interested as to why you think that as even on just x86 and x64 ther
Re: (Score:2)
Re:Why is it necessary to reverse engineer this? (Score:4, Insightful)
I think all first year computer science / programming / engineering students should be introduced to this and learn how to write programs for this environment first before moving on to modern systems. True power is being able to write useful stuff with only 64kb of ram and 1mhz of processor, and have it run in an acceptable time frame, and taking those skills and scaling up today's multi-core/ multi-gigahertz/multi-gigabyte address spaces.
Cheap memory accesses compared to instruction latency, over your whole memory space. Memory locality basically doesn't matter. Branching is also almost free, since you are not pipelined at all. If you would extrapolate a Z80 machine to multi-gigahertz and multi-gigabyte you would get a much simpler low-level structure than you actually have. Some of the lessons learned regarding being frugal make sense, but you will also learn a lot of tricks that are either directly counter-productive, or at the very least steal your attention from what you should be concerned with, even in those very cases where you are really focusing on performance and power efficiency (in addition to the myriad of valid cases where developer productivity is simply more important than optimality).
It used to be that you couldn't pre-calculate everything since you didn't have enough storage. These days, you shouldn't pre-calculate everything since it will actually be cheaper to do it again rather than risk hitting main memory with a tremendous amount of random accesses, or even worse, swap. Up to some quite serious size data sets a flat data structure with fully sequential accesses can turn out to be preferable to something like a binary tree with multi-level indirections. (Now, the insane amount of references even for what should be a flat array in anything from Java to Python is one reason for why even very good JITs fall short of well-written C, Fortran, or C++.)
Re: (Score:3)
Add to it the great book Programming the Z80 [freecomputerbooks.com] by Rodnay Zaks.
That book is one of the best books I have encountered when it comes to how to utilize a device.
Personally I think that it should be in the collection of books even if you don't aim to program specifically for the Z80 because it explains a lot of general CPU architecture and logic as well.
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
The Z-80 is one of a few chips that has the unusual feature that it is both simple enough to be built out of vacuum tubes or crude handmade integrated circuits (for example, you would need somewhere in the neighborhood of 5k to 10k tubes, complex but not impossible for a small machine shop) yet barely complex enough that you can run a simple version of Linux on it (I gather Linux hasn't yet been ported, but there
Re: (Score:2)
I wish I could have 64KiB on the platform I work with...
i remember (Score:3, Interesting)
Re: (Score:2)
While you can still buy a lot of embedded processors in DIP format, I haven't considered it very much - but yes, those were the days. Now you can just buy reasonable micros on affordable eval boards or other very simple boards with plenty of wire-wrap headers or solder points. You can cut a lot of the mundane work like breadboarding a voltage regulator, memory, osc, serial transceiver, etc.
Re: (Score:2)
Re: (Score:2)
Agree! Though I was a sixer, I miss those days. Wire wrap board, some '138s and JEDIC RAM. Put a 6522 (or 8255? in your case), maybe a 6551 and you have a computer. I had a hacked image of CBM BASIC that would take I/O from a serial chip. Did wonderful things with that.
I miss the 8052AH-BASIC very much, made a payphone controller board out of that one. That was one hell of a chip. So quick to code on. Self sensing serial speed, had the software to burn an EPROM, Give it +5, a colorburst xtal, and ha
Re: (Score:2)
Here's an ARM Cortex-M0 in DIP. [adafruit.com]
BASIC vs. Z80 assembly language (Score:5, Interesting)
Back in 1980 my parents got me a British ZX81 kit to assemble, with 1024 bytes of RAM. (I still have it buried in the closet along with my other antiques- AFAIK it still works.) It ran BASIC so slowly that you could actually read the code about as fast as it executed, so I was "forced" to learn assembly language. I was amazed by how fast it was- it ran a million operations in just a few seconds! (wow.) You had to start by writing a BASIC program:
10 REM AAAAAAAAAAAAAAAA
20 PRINT USR(16514)
Then you had to POKE each assembly instruction into the comment, starting at 16514 for the first "A". The comment line would slowly turn into "10 REM x&$bL;,$_)[vU7z#AAAAAAAA". The next line was 20 PRINT USR(16514) (printing out the return value from the BC register).
Saving any ZX81 program onto a cassette tape was excruciating- they recorded as several minutes of loud high-pitched screeching. Usually you needed to save them twice because it failed half the time. Then to load the program you had to cue the tape you had to find exactly where the start of the screeching was, rewind several seconds, play the tape, and only then could you hit enter on LOAD. (Otherwise LOAD got confused by the *click* noise when you pushed the play button on the tape player.)
You young people don't realize what an easy life you have.
Re: (Score:2)
What you describe has nothing to do with the Z80 processor but rather the ZX81 kit you had.
I had a Exidy Sorcerer which had a Z80 in it also. A great computer. It was my third but not my final Z80 based machine. All of them were tops for their time and a lot better than you're describing. You merely had a poorly done implementation.
It is important to differentiate the OS (what you're really complaining about) from the processor.
Re:BASIC vs. Z80 assembly language (Score:4, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Hah, I never knew that, but that's brought back a memory of disassembling "Halls of the Things" on the ZX Spectrum.
Was running through the code with my monitor/disassembler (DevPac, for those of you with long memories!) and I found the standard mapping table for the keyboard that pretty much every program had, but this time, immediately following it, was the ASCII text: "Yes cunt, a keyboard table". I nearly fell off my chair laughing... that someone had such hostility to spend the bytes at a time when mem
Re: (Score:2)
I fell in love with CP/M when I started working with it, after being familiar with several different OSes (mostly on mainframes). Here was an OS that got in my way no more than any other I'd tried, and it used few resources in doing it. (Later, MacOS became my favorite, since it actually seemed to help me, and then I encountered Unix. I haven't found anything I like better than Unix/Linux.)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Now we can reserve engineer TI calculators (Score:2)
Re: (Score:2)
Now if we can only figure out how to create 96 by 64 bit displays.
Stop the madness! It simply can't be done!
I had a different idea for that pin order (Score:5, Funny)
Definitely News For Nerds (Score:4, Interesting)
It's always refreshing to see stuff like this waft across the front page of /. every now and then - I wish there was a way to re-apply the "News For Nerds... Stuff That Matters" logo to top of the page only on stories like this.
(Pro-Tip: Please mod this "+1 Nostalgic" :) )
5v lines (Score:5, Informative)
It's not at all unusual for the 5v and 0v (Vcc and GND) lines to be in the middle of a DIP package (the Slashdot summary sort of implies it's an odd thing). It means the leads within the package are shorter for those lines, lowering parasitic inductance and capacitance for the power supply to the chip, generally you want the decoupling capacitors to be as close to the actual chip as possible so they can be as effective as possible as the power demands change. Putting the supply pins at opposite corners (like it's done on things like 14 pin 74-series standard logic) would very significantly lengthen the distance that the actual supply rails on the chip are from the decoupling capacitors.
Re: (Score:2)
Re: (Score:2)
Many modern chips that have analog components have the analog supply and ground close to the pins used for the analog functions (for pretty obvious reasons)
You many no longer be worried about running a few extra digital datapaths to make the outside data bus be in order but you still need to seperate analog and digital functions and that limits the output pins they can use
Super Geek Post (Score:3)
Don't underestimate the importance of our ROOTs. (Score:5, Insightful)
I'm a moderator of a major international electronics forum, and I don't have the number on just how many times the young generation feel completely lost when they're fresh out of school, trying to understand very complex structures. They either lack understanding of general electronics, or how the microprocessor works with different layers, ram, rom (especially embedded systems when they are working with complex IDE's with a maze of classes & libraries), they simply forget how the hardware works, and get to focus too much on programming.
I understand exactly that frustration, especially since this old geezer was lucky enough to grew up with basic home computers like the Commodore 64, Zx81 (Z80 cpu), Spectrum, Oric, Dragon 32, BBC etc. We often did our own hardware modifications, made fast I/O port load&save systems ourselves because we had a basic understanding of how the innards worked, and it really wasn't rocket science.
Sometimes it is relevant to take a step back in time (Like this article does, explaining some of the oddities with the Z80 processor), and spark interest in these old CPU's and their systems & possible uses even today. As an example, I have a HUGE stash of Micro-Controllers in my workshop, these are an absolute GEM to me. Why? Because they are very simple to work with. Like the good old Commodore 64 or ZX 81 - they don't have advanced hardware layers where you have to do special addressing to access certain memory areas or have to be kind to the operating system in order to write something to control your hardware (homemade or otherwise), it's as simple as writing a few pokes into memory...and you can turn on/off some external units such as relays, lights - or read on/off states from your sensors...maybe build your own satellite tracker the easy way, or control your homemade lawnmover unit.
And we still have VAST amounts of these MCU's unused all over the world, these are SUPER USEFUL (if you didn't get the above, think standalone apps...like each MCU was an app for a specific task). Many of these CPU's (MCU usually comes with internal memory/Ram/Rom/Flash/ and the most important part...an I/O) ready to use, just program it...and watch it go. If the kids of today understood this, they'd have a BLAST programming these (just watch the maker society with their modern versions...Arduino etc.) and the sky's the limit.
More articles like these thanks, brings
The refresh register is weird too (Score:2)
I had always wondered why the refresh register only counted 7 bits wide, which made that feature mostly useless when 64K DRAMs came out. (a few 64K DRAMs were made with 7-bit refresh, probably because of the Z80) Turns out that the increment/decrement circuit used in the Z80 had carry lookahead for groups of bits: 7 5 3 and 1. The I and R registers were implemented as a single 16-bit register, and to keep the I register from incrementing all the time, only the first group of the increment circuit was used,
Fred Weeks (Score:2)
I know Fred Weeks personally. He retired from his Zilog days a multi-billionaire and landed in Prince Edward County, Ontario.
Ob. War Story (Score:2)
I worked at Motorola in the late '80s in the Cellular Infrastructure Group. Moto's cellular switch was Z80 based, but it was a helluva hack. The thing had six Z-80s arranged in three nodes, each with an active processor and a hot standby. We had a custom MMU that extended the address space to 24 bits and could be mapped in 4096-byte blocks. Of the 16MB address space, 4MB was shared and simultaneously accessible by the active and standby processors.
It was mostly programmed in assembly, but we did have a "
And I thought.... (Score:2)
Another possible reason... (Score:2)
Anyone who ever designed circuitry regularly enough with the Z-80 ( I would have designed over 40 boards using the z-80 during my career ) always used to think they did it that way so you could put the ROM chip next to the processor, while only using a few through-board connections. A 16k ROM could easily be connected to the Z-80 on a single-sided PCB with just 6 jumpers that fit neatly beneath the Z-80 chip itself.
Maybe that's not the reason it was built that way, but working with other designers at the ti
Re:Up-to-the-minute reporting from Slashdot (Score:5, Insightful)
Now if only there were more comments to add to the understanding.
Re:The story (Score:5, Interesting)
The news what why it was that way.
And the Z80 was a major player in computing in the early personal computers before IBM PC. Even today it's still around in variants, and many have seen a variant of it in the Nintendo Gameboy. It was popular enough to render some clones as well, however they weren't always fully compatible, mostly on the undocumented instructions - which caused for example the Sinclair ZX80 to not work unless you had a real one.
Re: (Score:2, Insightful)
It's totally non-news.
It's basically a trivial fact that could probably have been answered just by ASKING anyone who actually knew about the details of the Z-80 development, but some dude decided to puzzle it out himself, slow /. news day, and bam, here's the article.
Hold on... I just had an epiphany about why manhole covers are round - give me a sec, I think I'm going to submit it...
Re: (Score:2)
Hold on... I just had an epiphany about why manhole covers are round - give me a sec, I think I'm going to submit it...
They could also be pointy or rounded equilateral triangles, leading to an interesting and annoying and dangerous pointy down dangle wedgie situation. But what is most annoying is that many sealed round lids have no lifter points on the underside, what were they thinking, so if it flips over before it settles into the ring you are reduced to prying opposite edges while wishing for a simple clamping magnet.
Re:Please, you are kidding? (Score:4, Interesting)
My father had built a Heathkit H89 computer built around a Z80. As a kid I earned money soldering together boards my father had designed that under software control would double the speed from 2 to 4MHz. The H89 actually had two CPUs since it was also a H19 terminal. While it didn't do color and was limited to text based graphics it was a nice machine. My father's computer had something like 4 floppy drives and a hard drive hooked up to it. It ran both CPM and HDOS [wikipedia.org] which was the first microcomputer operating system with loadable device drivers.
Later in college we used the Z80 for our microprocessor design class. The Z80 was trivial to wire up and included such things as automatic DRAM refresh support.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
But do you know WHY a V8 does not fire in ascending order?
Re: (Score:2)