On 8/6/2006 at 11:04 AM Dave McGuire wrote: And yet, to my eye, the Z80 architecture is about as bad as the 8086. Basically, a lot of instructions grafted onto an 8008 model. There were some architectures that held real promise back in the early days that never went anywhere; the GI CP1600, for example. A nice, reasonably orthogonal set of 16-bit registers witha straightforward instruction set. But I'll be the first to admit that GI was ham-handed about it--10 bit instruction width; poor I/O performance, etc. Most MPU instruction sets were cobbled together to fit within the constraints of silicon technology. Most mainframes of the time had rather elegant, straighforward instruction sets. There's a point of view that microprocessors were a devolution in the field of computer science, and I have to admit that it has some merit. Before the 8008/8080, who was even fooling with single-user mono-tasking operating systems as a serious effort? With mainfraimes we had graphics, database management, multi-user, multi-tasking, advanced architectures and all manner of work being done in basic computer science. Along comes the microprocessor and the siren song of easy money causes some very bright people to spend great chunks of their professional lives on MS-DOS, Windows and other already-invented-for-mainframes stuff. Right now, I figure we're somewhere in OS development on micros about where we were with a Spectra 70 running VMOS. In another thread, the discussion is centering around Microkernels (been there, done that on a mainframe) and the need to keep I/O drivers as part of the kernel. Why? Why should the CPU even have access to I/O ports and interrupts? Why doesn't every device have its own I/O processor with access to CPU memory? Or better yet, why not a pool of communicating I/O processors that can be allocated to the tasks at hand, leaving the CPU to do what it does best? Is silicon now so expensive that we can't advance to an idea that's more than 40 years old? Forgive the rant, but other than bringing computers to the masses, do microcomputers represent a significant forward movement in the state of the art? Cheers, Chuck

Chuck Guzis wrote: Yep. But to be fair I think that lineage really started with the 8080; the 8008->8080 differences were much more significant than any other step in the family. But I digress. I have to say that I do love the Z80, but I think I "forgive" some of its architecturally unclean aspects because it was the first architecture that I learned assembler on. Yes! I've long held the belief that "the computer world" is split into two completely different halves that don't even know of each other's existence. There's the side that started in the 1940s and had some of the world's most intelligent people working on them (which today only lives on in the mainframe world) and then there's the part that started in 1969 with a chip designed for a desktop calculator. The way I see it, everything we have to day, except for the mainframe world, is descended from the i4004...and as such, doesn't trace its lineage back to the 1940's...but to 1969's development of a processor for a desktop calculator. The "already invented for mainframes" thing has big examples in the minicomputer world as well. All this hoopla about SANs these days...we had that on our VAXen in, what, 1980? This is nothing new! When I read this paragraph, I wanted to stand up and cheer. You and I think very, very much alike in this area. If I didn't have to squander my time working like a dog just to keep the electric service turned on, I'd be building systems just like that. One of these days I'll get myself out of the dysfunctional "american dream" lifestyle of borrowing money to live beyond my means. Absolutely not, and I'd be really surprised if any experienced person actually thought otherwise. -Dave -- Dave McGuire Cape Coral, FL

Patrick Finnegan wrote: Funny guy. ;) But no, I'm not running any of them now. Money is REALLY tight for me these days...my current employment only eats a few hours per week of my time, but the pay isn't great. Combine that with some unexpected expenses involving an uninsured rental truck and a low bridge, and...no power for the Crays. I'd actually consider selling one or two of them at this point, if someone were to make a reasonable offer. -Dave -- Dave McGuire Cape Coral, FL

Chuck Guzis wrote: Shirley you jest? GI's devices were seriously crippled in terms of performance. We used to give the GI rep blank stares when he came peddling product -- "You don't REALLY think we can use these things for the types of products we design, do you?" And what are the relative *quantities* involved? As well as $$$? They were designed for different purposes. The problem *there* is that people were coerced into trying to make a device intended for one market serve another. Imagine the MPU had NOT come along when it did. Would folks have "coerced" mainframes to fit inside pinball machines? Or, under the hood in the automobile? Or, in the microwave oven? It would be a silly misapplication of that technology. You don't *need* (nor WANT) "graphics, database management, multi-user" in an appliance. OTOH, you *do* want it to fit in a few cubic inches, cost tens of dollars, run on a few watts and not require a DEC technician on call -- nor a support aggreement -- in case your microwave refuses to boil water for you today. The early (late 70's) "production" KRM's were Nova based. By the time you added the scanner to it, you had something the size of a WASHING MACHINE! No, the customer couldn't just "buy one and bring it $HOME/$WORK to use" -- someone went *with* it to get it running. And, was often "invited" to revisit it several times each year :> Replace the Nova with an MPU (actually, a couple since the speech was then moved to a DSP) and suddenly you've got a box that you can *mail* to a user -- and he/she can mail *back* (if there is a problem). Total cost of ownership drops tens of thousands of dollars. So, the $50K 1976 box is $3K in 2006 (dollars NOT adjusted for inflation!). Been there, done that. You'll find it gets very expensive, very quickly (even using "cheap MPUs"). Those "device controllers" still need an OS... and, thus, ways to protect who accesses what parts of the code within that processor -- so the same issues exist; they've just been moved to the IO processor instead of the "main" processor. Unless, of course, you want to design a custom piece of silicon to control a special type of device -- but that limits what types of devices you can *have*; besides disks, tapes, etc. will you have audio devices? a "BT device" (to encapsulate the BT stack)? a "servo motor" device? a "compression force" device? etc. And, what about devices that are, by their very nature, "ethereal devices"? (e.g., on very small MPUs, I often build a "FPU device") No. But you need to apply different techniques to address those problems. You're ignoring the fact that MPU's have caused *other* approaches to problems that have been poorly (sloppily?) solved in mainframe approaches. E.g., in the 70's, a classic paper on grapheme-phoneme conversion was written (Elovitz, et al. NRL report). The algorithm implemented therein was written in SNOBOL. Used over a megabyte of "core" (VM, actually). I'm sure the authors had no idea of how fast their code was. Nor did they even *care* (apparently) about designing the algorithm efficiently -- even if those changes were TRIVIAL (e.g., if a "rule" handles 80% of the input cases, wouldn't you apply THAT rule, first?) But, try to put that algorithm into an MPU and suddenly you realize, "hey, I'm not going to throw 1MB at this trivial problem!" Instead, you end up with about 6KB of code -- including the dataset. I'm always amazed when I see a gcc process grow to tens of MB just because there's a big *array* in the code. Sure, it's nice to just pretend you have infinite VM. But, couldn't a different approach compile said code on a 1MB *floppy* system? And, without the "consumerish" devices that MPUs have made possible, how much *real* work on real-time would be done? Would the solutions be "ivory tower" approaches to the problem (e.g., "maintain a HUGE table of all processes, sorted by priority and earliest deadline, etc.")? Or, would they be more efficient approaches that fit into the resource-strapped devices that are typically used to implement same? Sure! Would MP3 players have ever left the "lab" if there wasn't a *cheap* way of making them? Would they have just been an interesting intellectual exercise? Would digital cameras have come along to exploit image compression technologies? Camera *phones*?? The "problem" with the MPU was putting it in a "computer".

Chuck Guzis wrote: Exactly. And the "PC" has now become little more than an "Internet Workstation" for The Masses (I wonder to what extent this is also true in Business?) If the Google vision materializes, we'll be back to the "mainframe with terminals" architecture -- though those "terminals" will be considerably more graphical and empowered AND the "mainframe" will undoubtedly be a cluster of boxes instead of a single chassis. Yes. Amusing that we don't have "USER0" and "USER7" areas on C:, D:, .... :-( Well, put a 0x76 at 0x0038 and 0xFF is effectively handled. I particularly *like* the fact that 0x00 is NOP -- it lets you scribble over portions of PROMs that you no longer want without having to scrap the device entirely. This is largely a consequence of the fact that the MPU-based world essentially "started over". E.g., why do we have limits on the sizes of disk volumes (even in the *Sun* world?). Why do we have Y2K problems? I mean, can't people *see* that disks WILL get bigger, that the calendar *will* continue beyond Dec 31, 1999, etc.? Sure, some of it is resource-bound (e.g., who would need anything bigger than FAT12 for a ~1MB floppy?). But, other things are false economies brought about by lack of vision and laziness on the part of implementers. (are Suns *that* squeezed for resources that they have to save a few *bits* to force the IPL to reside in the first 2GB of a drive??) I don't think the problem is the MPU as much as it is the fact that "competition" has disappeared from *that* (desktop) marketplace. It's just one or two architectures that are being rehashed over and over and over and... Some of the earlier architectures were much more innovative and expressive... but they just went away. As did many of the OS's and applications. The same is true of even newer "inventions". They get driven to "marketable" products at the expense of good features, reliability, etc. (e.g., Inferno is a neat idea that is quickly being subverted by market pressures). <shrug> Maybe we should al have become PLUMBERS! After all, WC's haven't changed *that* much in the past 100 years... :>

Chuck Guzis wrote: And try to explain to her why 10-penny nails aren't called "dime" nails ;-)

On Sunday 06 August 2006 03:52 pm, Don wrote: <...> Any of you guys done anything with clustering? I'm seeing references to it in the linux context but don't know what if anything I could apply it to offhand. OTOH, after my initial exposure to DOS (and for quite some time after that time during which I was still using CP/M) I thought that subdirectories were a rather neat concept and that it should be possible to implement them in something that was pretty close to CP/M. The concept is already partially dealt with in terms of "library files", though that could've gone further than it did. Maybe someday I'll return to that to play with the idea. OTOH I like the idea of unwritten eprom locations showing up as they do, it makes for a handy "oops!" vector without too much coding needed. <...> Indeed. Good question, and one that I've never seen anything resembling a good answer to. Or, "What were the assumptions implicit in this?" <...> Got any specific exsmples you'd care to kick around some? Not sure what you're referring to here. Heh. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

On Sunday 06 August 2006 03:05 pm, Chuck Guzis wrote: Yeah, but... Back around 1970 or 1971 I got a hold of my first TTL data book, which I still have. And in times when I had some leisure to play with ideas, I worked my way laboriously through some vague notions of what it might take to "build a computer". What info I could find back then was mostly of a very general nature, out of library books and such, and when it came to actual machine architecture I really had no clue whatsoever. And the best I could come up with, for something that promised to be vaguely functional, would've used about 800-900 TTL chips. It's probably a good thing that I never actually started to build such a thing. I was rather pleased to see a short mention in a magazine at one point back there someplace of a guy's homebrew TTL computer, which as it turned out also used about 900 TTL chips. There was a picture, of this thing spread out across the floor, where his cat had knocked it (and having a cat here that's currently into sometimes being a real PITA when she goes into "predator mode" I can understand now how such a thing would happen. :-) As the article pointed out, when it ended up there it still worked, so he left it there. That was one heck of a lot of boards and wire-wrapping and power distribution and cabinetry and not very much flexibility and probably a whole lot of other issues that I was not aware of in my relatively ignorant state in those days. Then that "Mark-8" was published in Radio-Electronics. And the Altair a bit later. And when I first looked at the 8080, I really wasn't all that impressed. I mean, you had to feed the thing those silly "machine code" instructions while the thing I'd been envisioning back then would take it in _ASCII_ (!) which, of course, was a lot of the reason for the inflexibility, but I didn't know any better back then. But eventually I came around... Mostly because you could do SO much more with not really all that much in terms of hardware. Yup. I'd still liked to have seen somewhat more orthagonality in the instruction set, and maybe a bit additional, like relative jumps, one of the things I do like about the z80. I'd like to be able to use DE or BC as many ways as you can use HL for example. The z80 added stuff I've never personally found all that useful otherwise, and have never used the index registers (yet) or the alternate set, all that much. And the lack of orthagonality or symmetry is something that I've also noticed in a lot of the peripheral chips as well. Write-only registers that I can't read back? WTF? Address space was never that much of a scarce commodity as far as I can see. The LSI-11 was my first exposure to a "real" computer in terms of something I could actually get my hands on and try and do stuff with. I think I even still have a "quick reference card" in my desk somewhere. And although the hardware was very weird by comparison with what I'd already wrapped my brain around (and my one attempt to interface to that bus was not successful), the software side of it seemed *so* much better than that intel stuff. Of course, trying to get a grip on RT-11 and the stuff they seemed to sort of assumed you'd know about was yet another matter. Sometimes? :-) Mainframe and mini people knew about a lot of stuff, and I'm sure that this is only one item on a potentially very long list, but somehow that knowledge never seemed to transfer over. For some reason I'm reminded of the stage kids go through when they get to a certain age (and ain't *I* sounding like "the old phart" here :-) where all of a sudden they start having all these *wonderful* insights into all sorts of things, and come to the (usually erroneous) conclusion that their parents and other people "just don't see it" for some reason, and usually don't have a clue about what else might be considered in whatever the context is that they might perhaps be missing. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

On Sunday 06 August 2006 08:04 pm, Chuck Guzis wrote: I have no doubt whatsoever from this point of view now that there was an awful lot of what I was thinking back then that was totally wrong. And I'm afraid of someday finding one or more of my old notebooks and confirming that. :-) I'm not sure if I was even aware of the concept of bit-serial back then. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

On 8/8/2006 at 11:11 AM Dave McGuire wrote: When I (and I'm sure, others did likewise) wrote Z80 code, the alternate set was used for the highest-priority interrupt, usually the interval timer (I refuse to call it a clock, but could also be a byte-interrupt data acquisition routine. There was no possibility of confusion that way--and one made the best use of the reduced latency. BTW, if you look at early Intel documentation, the B,C D and E registers are referred to as "Index registers". A strange twist of the term, isn't it? Other than the relative jumps, the enhanced instruction set of the Z80 rarely brought much speed increase by itself. For example, moving a block of bytes using LDIR isn't really much faster than using a MOV A,M/STAX D type of loop. On the other hand, the INI and OTI instructions was very welcome when one had to deal with a peripheral whose I/O port addresses weren't known in advance. The alternative on the 8080/8085 was hot-patching code--an impossiblity if one was executing out of ROM--one had to copy the applicable code into RAM and execute it there. Not a great feature if the I/O ports in question controlled the bank-switching hardware and you were trying to do a RAM diagnostic. I've wondered about something for years, however. Did anyone ever make use of the fact that an INI or OTI instruction placed the contents of both the B and C registers on the Z80 address bus? It would seem to be a simple way of expanding the I/O space to 64K ports. Cheers, Chuck .

On Tuesday 08 August 2006 12:25 pm, Chuck Guzis wrote: <...> Yes. Most of that "extra" stuff I never used. That would seem to make it a bit awkward. I didn't know they did that. And asserted the usual I/O control lines? Hm... OTOH, I never even came close with any of the ideas I was toying with to filling up the i/o address space, and then there's always memory-mapping stuff. Anything I'm doing on that platform isn't going to be that upset over a few K less ram to work with. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

On 8/8/2006 at 3:35 PM Don wrote: Yes! I prefer to think of it as a 16-bit port address. But the idea's the same, instead of latching an index value into a register file on a device, one can simply use the value of the B register as the index and do away wit hthe latch entirely, saving valuable time. The NSC800 has a configuration port at 0bbh, which can be modified with the register-indirect form of the OUT instruction, but not the immediate-port form. Cheers, Chuck

On 8/8/2006 at 4:45 PM Don wrote: You mean that IN A,C won't get past the assembler? That ain't a buglet--it's a typo. Cheers, Chuck

On Tuesday 08 August 2006 11:11 am, Dave McGuire wrote: What sort of stuff do you do with them? Agreed! -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

Dave McGuire wrote: IX and IY are great if you are used to writing code where you deal with lots of struct's or diddle with stack frames. For most folks tinkering, they never figure out the value of them :-( Alternate registers are useful for interrupt handlers -- *if* you ensure that they can't be nested. You can cheat and use AF in one IRQ and the other pairs (EXX) in another IRQ (of course, assuming you only need AF in the one and don't need A or F in the other! :> )

woodelf wrote: Pretty skimpy to try to work with just 8 bytes of RAM :> (and F would be difficult to access). The '7180 was a great part during it day as it had 512 bytes of RAM, internal (and 16K of OTP). I would use them to throw together dog-and-ponies for prospective clients. You could even *leave* the prototype with them and not fear that they were going to "dump the ROM"... ;>

On 8/6/2006 at 11:52 PM William Donzelli wrote: Back when Atari was on Moffett Park Drive across the street from CDC, they used to get a lot of walk-in applicants from CDC. Eventually, Atari stated in their employment ads "No mainframe programmers, please". Not a good move in my estimation. Cheers, Chuck

Roy J. Tellason wrote: There's nothing wrong with the 8080/Z80 lines. For the era they are in, their opcodes are reasonable, and not worse than the 6809 or 6502. Not as clean as they could be, but not so bad either. When you attempt, however, to build another chip, the 8088 and still keep compatibility with the 8080, that's where you're starting to make the wrong turn. Now, the 8086 itself, is also reasonably ok, but then, you get into weird issues where you can only use some registers for some operations, but not others. Then, the next wrong turn was the 386 line. Once you go into 32 bit mode, the old 8 and 16 bit opcodes no longer make any sense and the whole thing just gets ugly. Intel should have gone to a new set of opcodes altogether - a clean 32 bit set of opcodes with enough registers. To provide an example: SPARC is a 32 bit RISC architecture. Sun could have really screwed things up when they went to 64 bits. Instead, they did the right thing. They extended all of the registers to 64 bits, and added a new 64 bit status register. So your code is backwards compatible to 32 bit code, however, with a simple switch, it can run in 64 bits without getting all ugly, without things like segment registers and weirdo addressing modes. It started out cleanly from the start, and this perhaps helped them move to 64 bits more easily.

Chuck Guzis wrote: Though annoying that they had to partition them into ADDRESS and DATA :-(

On Sunday 06 August 2006 06:10 pm, Ray Arachelian wrote: That's one of the things about these parts that's always bothered me. Yes. Sounds good to me, though I'm not familiar with that stuff, or a lot of what else gets talked about in here. But learning about it all is a part of why I'm in here anyway, so that's not much of a problem except for those times when I just don't follow stuff... -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin