As it is now, running z80 production must no longer be profitable for Zilog, but some other manufacturer can license z80 production. Right? If there is a demand someone will produce them It was a good run though. Bill On Fri, Apr 19, 2024, 5:19 PM Chuck Guzis via cctalk <cctalk(a)classiccmp.org> wrote:

On 2024-04-19 8:07 p.m., Fred Cisin via cctalk wrote: There still are RADIO SHACK 8080A's still on ebay, with @RARE@ prices. NO thank you, z80's are the way to go. Now is a good time to stock up for any z80 projects or repair, while they are $10 or less on epay.

On Fri, Apr 19, 2024 at 09:34:42PM -0700, Chuck Guzis via cctalk wrote: [...] Unless people start panic-buying them, Z80 chips are likely to languish in Mouser etc's warehouses for years. After all, Zilog wouldn't stop production of something in high demand. There's this thing called "inflation", which does tend to become somewhat significant after four decades. In the mid-80s, a pint of beer cost about 70 pence. I've escaped that benighted island, but according to friends who were not so lucky it is now now seven quid in London these days. That's enough to drive you to drink, except, well...

On 4/20/24 01:37, Peter Corlett via cctalk wrote: Absent the price of a pint at the local pub, the sub-$1.00 price for a Z-80 was remarkable for the time. Well within the range of the price range of MSI or even DRAM chips. I note that at the time, Zilog was being run as a subsidiary of Exxon, the oil giant. Other acquisitions of the time, (Qyx, Qwip and Vydec in the Office Systems, Ray Point uranium ore processing) fared as badly from mismanagement as did Zilog. After the relative flop of the Z8000, it seems that the Z80 remained the bread-and-butter part of the whole venture. The other acquisitions appear to be consigned to the dustbin of history. Zilog was fortunately saved from that fate by a buy-back by employees and management in 1989. Still, the succeeding years were pretty rocky, including a Chapter 11 bankruptcy. That Zilog survives today is remarkable. --Chuck

My first exposure to a computer at home was a BBC Micro with 32kB of RAM and 32kB of ROM. Included in this was a 16kB BASIC ROM which was regarded as fast and powerful, featuring 32 bit integer variables, 40 bit floating point variables, variable length strings, structured programming constructs and everything accessed by keyword statements rather than PEEK this and POKE that. This was implemented by a humble 6502 running at (mostly) 2MHz, with one 8 bit arithmetic register, two 8 bit index registers, one 8 bit stack pointer, a 16 bit program counter and a few flag bits. I would have expected that a computers featuring a Z80 with its larger register set, 16 bit arithmetic operations, richer instruction set and general bells and whistles would have been able to produce a much superior implementation in terms of speed or features or both but I never came across one. Why is that? Did the Z80 take more cycles to implement it's more complex instructions? Is this an early example of RISC vs CISC? Regards, Peter Coghlan

Cycles per instruction is one aspect of RISC vs. CISC but there are more, and cycles per instruction may not be the most significant one. Given enough silicon and enough brainpower thrown at the problem, CISC machines can be made to run very fast. Consider modern x86 machines for example. But the key point is "given enough silicon...". I think the significance of RISC isn't so much in cycles per instruction but rather in simplicity of implementation (for a given level of performance). It's not just single cycle instructions. In RISC architectures it is often easier to achieve pipelining and parallelism. Consider what's arguably the first example, the CDC 6600 with its parallelism, and its sibling the 7600 which made the rather obvious addition of pipelining. Simplicity of implementation means either lower cost for a given level of performance, or higher achievable performance for a given level of technology, or lower power per unit of performance, or easier power management optimization, or any combination of the above. Consider ARM machines vs. x86. It's not so much that ARM machines go faster but that they do so on a fraction of the power, and that they require only a small amount of silicon to do so. One other factor is that RISC machines rely on simple operations carefully arranged by optimizing compilers (or, in some cases, skillfull programmers). A multi-step operation can be encoded in a sequence of RISC operations run through an optimizing scheduler more effectively than the equivalent sequence of steps inside the micro-engine of a CISC processor. paul

On 4/22/24 12:31, ben via cctalk wrote: > Classic cpu designs like the PDP-1, might be better called RISC. > Back then you matched the cpu word length to data you were using. > 40 bits made a lot of sense for real computing, even if you > had no RAM memory at the time, just drum. I'd call the CDC 6600 a classic RISC design, at least as far as the CPU went. Classes were given to programming staff on timing code precisely; I spent many happy hours trying to squeeze the last few cycles out of a loop (where the biggest bang for the buck was possible). I think bitsavers (I haven't looked) has a document or two on how to time code for that thing. --Chuck

On 4/22/24 13:02, Wayne S wrote: That certainly was true for the 6600. My unit manager, fresh out of UofMinn had his first job with CDC, measuring wire loops on the first 6600 to which Seymour had attached tags that said "tune". But then, take a gander at a modern notherboard and the lengths (sic) to which the designers have routed the traces so that timing works. --Chuck

On 2024-04-22 5:21 p.m., Chuck Guzis via cctalk wrote: Shortly after I started at IBM I assisted one of the senior CEs doing engineering changes on a 3031 and the back of the logic gates was a mass of what IBM called tri-lead, when I saw it I wonder how it could possibly work.  The tri-lead is basically a 3 wire ribbon cable that has the two outer wires grounded and is precisely made to have reliable characteristics.  It was explained to me that sometimes they would change the length of the tri-lead in a connection to adjust signal timing. I am not sure when IBM started using tri-lead but I also recall seeing a 168 that had some third party memory that was in a box hung on the end of a frame and had a large bundle of tri-lead coming out of it that disappeared under the covers.  The site CE told me that those tri-leads where all plugged into specific locations on the back of the boards on one of the card gates, and if they had a problem with memory, they would call in the techs that looked after the third party memory and have them disconnect it all.   The last system I saw with tri-lead was a 3081 most of the logic was in TCMs but the memory was on a separate card gate and connected to teh main CPU board with tri-lead. Paul.

Hey, I did that on Sunday afternoons on the Star-100 with Lincoln and his son PD when I was in 8th grade. I never became a manager though :-) Chris -- Chris Elmquist

On Monday (04/22/2024 at 08:55PM -0700), Chuck Guzis wrote: I seem to remember (poorly) that it was very small diameter coax but I don't remember the termination method. I remember more about the Tek oscilloscope on a cart that we used than what we were actually doing. I don't recall that we actually cut and terminated any cables. We were just measuring the skew and writing it down and then I think a "professional" was going to come around later and actually adjust the line length. Entirely possible we were just doing busy work to stay out of trouble and not going to be part of the actual solution. But it was still educational. Close. I think 48 yrs. I first met PD Lincoln in 1976 when I moved into the Mounds View School district. Then I discovered his dad was doing some pretty cool stuff at work... I think they were working on the CY203 then too but there was still a Star on the floor which is what we "played" with. For those playing along, this was the CDC Arden Hills Operations (ARHOPS) in St. Paul, MN. The CDC Advanced Design Lab (ADL) was here and it's where all the supercomputing hardware development took place after Seymour left CDC. So, they did the Star-100, CY203, and CY205 there and then in 1983 spun the entire ADL off into what became ETA Systems and we did the LN2 cooled ETA10 there. Understood. It's all I know except for recently experiencing summer in Albuquerque so we might be 180 degrees (so to speak) out of phase on that :-) Chris -- Chris Elmquist

An early cache, though not called that, is the track buffer in the ARMAC, a 1955 or so research computer built at CWI (then called MC) in Amsterdam. Its main memory was a drum, like its predecessors, but it would keep the most recently accessed track in memory (core?) for fast access. That was handled in hardware if I remember right, so it's exactly like a one-entry cache with a line size of whatever the track length is (32 words?). paul

On 4/22/24 13:53, Paul Koning via cctalk wrote:

Might well be, I don't remember. Or moving the SB3 (the loop counter) to be right after the loads is probably helpful. The full answer depends on understanding the timing, both of the instructions and of the memory references that are set in motion by them. I never had my hands on a 6600, only a 6400 which is a single unit machine. So I had to do some thinking to understand why someone would do a register transfer with L (shift operation) rather than B (boolean operation) when I first saw that in my code reading. The answer is that both instructions take 300 ns, but they are in different functional units on the 6600 so they can start 100 ns apart. paul

Compilers do that with what is called loop rotation optimization. On 4/22/2024 3:59 PM, Chuck Guzis via cctalk wrote:

On 4/21/24 20:06, Peter Coghlan via cctalk wrote: Z80 is blessed with a 4-bit ALU, verified by reverse engineering dieshots ( https://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html ). Die real estate forced the design to do without a full 8-bit ALU. When you have a 4-bit ALU, and you are doing 16-bit math, you will need 4 cycles through the ALU. Neither 6502 nor Z80 are RISC.  6502 simply runs very efficiently thanks to the design decisions made; 8 bit ALU, 8 bit registers for everything, including stack.  Math is fast.  Biphase clocking allows what could be considered a precursor of double-data-rate designs. The Visual6502 project shows the 'tick-tock' of it very well. If you want to see what can be done with sufficient real estate on the chip and using more modern design methodologies, pick up a copy of Monte Dalrymple's book "Microprocessor Design using Verilog HDL' ( https://www.elektor.com/products/microprocessor-design-using-verilog-hdl-e-… )in either ebook or paperback form (I bought both); Monte was responsible for Z380 among other designs, and they are very efficient.  Today's eZ80 builds on that, and is as efficient as the 6502 and much, much faster. There are many softcores out there, so Z80 lives on in both those as well as the Z180 (several parts are EoL (either last-time-buy or obsolete) but some parts are still Active) and the eZ80 (most instructions on eZ80 are single-cycle, and the chip is pipelined; eZ80 has a 24-bit ALU; plus, eZ80 is a very capable microcontroller).  The Z84015, in both 6 and 10MHz variants, still shows as Active at Digikey.  ALL are of course surface mount. Through-hole anything is a dying breed. The Z80 is dead; long live the Z80.

On 4/22/24 08:36, Lamar Owen via cctalk wrote: I don't know if this applies to the Z80, but on the 8080, 16-bit increment/decrement is handled by a separate increment block (also used to advance the P-counter and stack operations). Probably one of the reasons that INX/DCX doesn't set any flags. --Chuck

On 4/22/24 12:18, Chuck Guzis via cctalk wrote: 16-bit INC and DEC are indeed handled by a separate block, which also gets used to increment PC and decrement SP at the appropriate times.  Ken's page on the 4-bit ALU has a 'mapped' dieshot showing it. Ken covers it operation in the blog article https://www.righto.com/2013/11/the-z-80s-16-bit-incrementdecrement.html

A bit of a postscript: The ALU on the 8085 according to Ken is 8 bits wide. https://www.righto.com/2013/01/inside-alu-of-8085-microprocessor.html --Chuck

Microcode? Of course the VAX started out as a modified PDP-11; the name makes that clear. And I saw an early document of what became the VAX 11/780, labeled PDP-11/85. Perhaps that was obfuscation. Anyway, I would think such a small microprocessor could emulate a PDP-11 just fine, and probably fast enough. The issue isn't so much the instruction set emulation but rather the electrical interface. That's what would be needed to be a drop-in replacement. Ignoring the voltage levels, there's the matter of implementing whatever the bus protocols are. Possibly an RP2040 (the engine in the Raspberry Pico) would serve for this, with the PIO engines providing help with the low level signaling. Sounds like a fun exercise for the student. paul

On 4/22/2024 2:30 PM, Paul Koning wrote: Well, that's what I would have called it. :-) I have never seen anything but the vaguest similarity to the PDP-11 in the VAX. I know it was called a VAX-11 early on but I never understood why. I wasn't thinking just the PDP-11. I was thinking about the ability to replace failing CPU's of other flavors once production come to an end. I suspect that is far enough in the future that I won't have to worry about it, but it sounded like an interesting project. bill

On 4/22/24 19:14, Bill Gunshannon via cctalk wrote: Umm, the VAX was a very obvious extension of the PDP-11 instruction layout to 32 bits.  The PDP-11 had a 3 bit register address and 3 bit addressing mode.  On the VAX these were each extended to 4 bits.  On the 11, the opcode field was 4 bits, although more bits were available on unary instructions.  On the VAX, the opcode could be either 8 or 16 bits. Quoting from the VAX11/780 Hardware Handbook Preface "VAX-11/780 is DIGITAL's 32 bit extension to its 11 family of minicomputers." This is the first sentence in the book. As somebody who programmed PDP-11s and VAXes in assembly language (Macro 11 and VAX Macro) I found the similarities VERY strong. Just that the 32-bit architecture took the constraints of the 16-bit PDP-11 away. Jon

Probably not. Cycle accurate simulation is very hard. It's only rarely been done for any CPU, and if done it tends to be incredibly slow. I remember once using a MIPS cycle-accurate simulator (for the SB-1, the core inside the SB-1250, later called BCM-12500). It was needed because the L2 cache flush code could not be debugged any other way, but it was very slow indeed. Almost as bad as running the CPU logic model in a Verilog or VHDL simulator. I don't remember the numbers but it probably was only a few thousand instructions per second. Then again, for the notion of a drop-in replacement for the original chip, you don't need a cycle accurate simulator, just one with compatible pin signalling. That's not nearly so hard -- though still harder than a SIMH style ISA simulation. paul

On 2024-04-22 1:02 p.m., Chuck Guzis via cctalk wrote: Real computers use glow tubes like the NE-2 or the NE-77.:)

________________________________ From: ben via cctalk <cctalk(a)classiccmp.org> Sent: Monday, April 22, 2024 12:43 PM To: cctalk(a)classiccmp.org <cctalk(a)classiccmp.org> Subject: [cctalk] Re: Z80 vs other microprocessors of the time. On 2024-04-22 1:02 p.m., Chuck Guzis via cctalk wrote: Real computers use glow tubes like the NE-2 or the NE-77.:) For those that don't know what a UV(UX)201 was, it was most commonly used for audio amplification in early battery powered radios. These used a lot of filament current, not like later miniature tubes. They had a UV(UX)200 tube for RF detections that worked better as a grid leak detector, I think because of less cutoff voltage needed as a detector. The A series used a better getter and lower current filament ( one or both? ) but still used a lot of filament current. Dwight

What about the coincidence that a lot of today's logic runs on 3.3 volts, just about the same as the first generation of IC logic (RTL). Interesting! paul

Cycle accurate emulation becomes impossible in the following circumstances: * Branch prediction and pipelining can cause out of order execution and the execution path become data dependent. * Cache memory.  It can be very difficult to predict a cache flush or cache miss or cache look aside buffer hit * Memory management can inject wait states and cause other cycle counting issues * Peripherals can inject unpredictable wait states * Multi-core processors because you don't necessarily know what core is doing what and possibly one core waiting on another core. * DMA can cause some CPUs to pause because the bus is busy doing DMA transfers (not all processors have this as an issue). * Some CPUs shut down clocks and peripherals if they are not used and they take time to re-start. * Any code that waits for some kind of external input. When I was working for a 6800 C compiler company we could simulate all 68000 CPUs before the 68020.  The 68020 with it's pipelining and branch prediction made it impossible to do cycle accurate timing. On 4/22/2024 1:46 PM, Paul Koning via cctalk wrote:

True, if 1 cycle per second or minute is an acceptable emulation speed🙂. For that kind of emulation to work the emulator needs to be fed the same tasks in the same order and for the same core.  This is even more true when the CPU is waiting on internal or external resources.  If you can emulate all of the cores, all 3 (or more) levels of cache, all possible branch prediction, all possible out of order execution and all possible external influences then yes you can emulation anything.  But that would be like using one of today's petaflop hyper computers to emulate an ARM 9 running at the speed of a Z-80 or even slower. On 4/22/2024 2:57 PM, Paul Koning wrote:

Well not possible with the hardware available at the time. If one cycle per minute or less is acceptable then I guess it was possible. That is why we used in circuit emulators to do cycle accurate counting on more complex machines.  This machines were clunky and unreliable but they worked for the most part. On 4/22/2024 3:12 PM, Fred Cisin via cctalk wrote:

Well, the SB-1 is a multi-core pipelined machine with multiple caches and all sorts of other complications. And the company certainly had a cycle accurate simulator. They were reluctant to let it out to customers, but we leaned hard enough. It was slow, indeed. Certainly not a cycle per minute; I'm pretty sure it was a whole lot more than a cycle per second. Given that the code I was debugging was only a few hundred instructions long, it was quite acceptable. Speaking of slow emulation: a CDC 6600 gate level model, in VHDL, is indeed slow. Now we're indeed talking about a cycle per second. I'm thinking I could translate the VHDL to C and have it go faster (by omitting irrelevant detail that VHDL carees about but the simulation doesn't). paul

Well, it was beyond the PC's and Sparc stations we had access to at the time. On 4/22/2024 3:28 PM, Christian Kennedy via cctalk wrote:

On 4/22/24 14:09, Bill Gunshannon via cctalk wrote: Microcore Labs has done this using a Teensy plus a small adapter board; see https://microcorelabs.wordpress.com/2022/05/11/mclz8-zilog-z80-emulator-in-… (Github repo: https://github.com/MicroCoreLabs/Projects/tree/master/MCLZ8 ). There are others there as well.

Sorry, I guess this should dead end, it is too far off track. I will still post this since I was among those misled into thinking it had an 1802 microprocessor. The galileo had an 1802, but it suicided. from Wikipedia: It has been erroneously reported[41] on the Internet that the Voyager space probes were controlled by a version of the RCA 1802 (RCA CDP1802 "COSMAC" microprocessor), but such claims are not supported by the primary design documents. The CDP1802 microprocessor was used later in the Galileo space probe, which was designed and built years later. The digital control electronics of the Voyagers were not based on a microprocessor integrated-circuit chip. <pre>--Carey</pre>

On Tue, 2024-04-23 at 13:27 +0200, Peter Corlett via cctalk wrote: I shared an office with a lady who got a computer from Ohio Scientific that had both a Z80 and a 6502. It also had two 5/25" floppy drives. She also got a tee-shirt that said "I have two floppies." Except she didn't.

On Tue, 23 Apr 2024, Van Snyder via cctalk wrote: aside from her floppies, . . . a significant portion (I remember at one time, somebody at Apple said 20%) of Apple users had the Microsoft SoftCard Z80, or imitations thereof. At least one of the Apple imitations had both 6502 and Z80. -- Grumpy Ol' Fred cisin(a)xenosoft.com

Did the Dimension 68000 (a multi-processor machine) have Z80 and 6502? Commodore 128 had Z80 and 6502 On Tue, 23 Apr 2024, Mike Katz wrote: > I think Ohio Scientific made a computer called the 3B or something like that > that had a 6502, a Z-80 and a 6800 in it.  If my memory serves. > > On 4/23/2024 7:00 PM, Fred Cisin via cctalk wrote: >> On Tue, 23 Apr 2024, Van Snyder via cctalk wrote: >>> I shared an office with a lady who got a computer from Ohio Scientific >>> that had both a Z80 and a 6502. It also had two 5/25" floppy drives. >>> She also got a tee-shirt that said "I have two floppies." Except she >>> didn't. >> >> aside from her floppies, . . . >> a significant portion (I remember at one time, somebody at Apple said 20%) >> of Apple users had the Microsoft SoftCard Z80, or imitations thereof. >> >> At least one of the Apple imitations had both 6502 and Z80. >> >> -- >> Grumpy Ol' Fred             cisin(a)xenosoft.com

On Tue, 23 Apr 2024, Bill Gunshannon via cctalk wrote: Yes. But the original comment that I was responding to was asking Z80 and 6502. Cromemco also had a 68000 and Z80 machine. a friend of a friend had one, and turned up his nose at the thought of a Tandy machine. BTW, I found out about the Dimension 68000; it was rather expensive https://en.wikipedia.org/wiki/Dimension_68000 68000, Z80, 8086 -- Grumpy Ol' Fred cisin(a)xenosoft.com

On 2024-04-23 8:40 p.m., Chuck Guzis via cctalk wrote: I remember Bill Godbout's PACE ads. Now I got the $$$ and time I can't find any chips.

On Tue, 23 Apr 2024, Chuck Guzis via cctalk wrote: Did he, or anybody else, make an S100 6502 CPU board?

On Wed, 24 Apr 2024 at 01:18, Bill Gunshannon via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: If we're talking about machines with a Z80 and 6502, it would be remiss not to link back to the machine mentioned in the original message - the BBC micro, with its onboard 6502 and "Tube" interface which could take a second processor option, including - Z80 - 65C02 / 65C102 - NS 16032 (ahem 32016) - 8088 (Torch) / 80186, 80286 (last developed but never released) - ARM1 (Original ARM development board. Rare as hens teeth :) / ARM7 (someone having a laugh in later years) Typically the second processor would run as primary, using the original 6502 to handle input, display and I/O (and on 32016 you *really* wanted someone else to deal with anything time critical like interrupts :) David

On 2024-04-24 2:55 p.m., Gordon Henderson via cctalk wrote: This would be great, but I live on the other side of the pond and BBC anything is hard to find, let alone Micro's. Where is my "Dr. Who". Ben.

https://www.youtube.com/watch?v=iJeu3LCo-6A Dr who ads for prime.

On 4/24/24 13:10, David Brownlee via cctalk wrote: Thats the way we did it on the Poppy--the 80186 did the I/O for the 80286. You could run CP/M-86 or MSDOS without the 80286. I never did figure out if the 80286 at 6MHz was outperformed on MSDOS by the 8MHz 80186. --Chuck

On Tue, 23 Apr 2024, Van Snyder via cctalk wrote: That was pretty cool The developer of it said that when he met with Apple's lawyers, "Magic Sack" was as close to "Mac" as they would let him be.

After learning more about the PALM processor in the IBM 5100, it has a similarity to the 6502 in that the first 128 bytes of RAM is a "register file." All its registers (R0 to R15, across 4 interrupt "layers") occupy those first addresses. In addition, they are physically on the processor itself (not in actual RAM). I've been meaning to come up with a sample PALM program that verifies if there is any performance advantage on that (that is, something that "does stuff" with data in addresses 0 to 127, then "does that same stuff" in a higher address like $800+ and see if there is a noticeable performance difference). The earliest document I can find on PALM is from 1972 (or just a few months after the 8080 - the actual initial production date of PALM is unknown, the 1972 date is just when IBM documented the instruction set). But I think the IBM System/3 had a similar design (or at least, just I recall a mention of the System/3 registers are in RAM -- not sure if that's literal or just address-access-wise, but in any case the System/3 was said to be pretty difficult to program for). Anyhow, to me the PALM may be an earlier "RISC" approach in that its instructions are always 2-bytes (4-bits for a main opcode -- yes only 16 categories, then a few bits for a "modifier" while the middle pair of bits specify a register R0 to R15 that the instruction involves), in contrast to the variable instruction length used by the System/360. There is one exception in PALM where a kind of "long jump" instruction is followed by another 2-bytes that is the target address. You won't hear much about PALM - though I am excited that emulation support for it has recently been added into MAME! I ponder if maybe Chuck Peddle somehow crossed paths with PALM in his early engineering career, or if in some indirect way there was some lineage or connection there (in a "dude, your processor doesn't need to be that complicated, I know a system that in 16 instructions does all sort of stuff" kind of way). BTW, IBM's costs list during the IBM SCAMP development put the PALM processor card costing about $300 (in c. 1973). All that said, in early 1970s, I don't think anyone was yet using the term RISC vs CISC. -Steve v* On Sun, Apr 21, 2024 at 7:50 PM Peter Coghlan via cctalk < cctalk(a)classiccmp.org&gt; wrote:

On 4/19/24 21:07, Fred Cisin via cctalk wrote: Harris also made an all-CMOS plug-compatible Z-80.  I used it in a low-power project. Jon

Who still uses the Z80 line for new projects? Wouldn’t it be easier and cheaper to just use an Arduino or Raspberry Pi? Sent from my iPhone

Good point but i’m not an trained EE, just a hobbyist so i’m just curious. I buy Z80’s and other’s for repair projects but … Sent from my iPhone

On 4/20/24 13:16, Wayne S via cctalk wrote: I dissected a dead coffee maker last week that has a current-design 8051 clone running the control board. Well-known instruction sets and "Nobody cares if I clone this" make powerful arguments Doc

On 2024-04-20 8:33 p.m., Mike Katz via cctalk wrote: I am wishing for a Quality Product, cheap crap is not always better. USB comes to mind. 256Kb ram is only 32K 64 bit words. Cache memory never works. My $5 internet toaster, just exploded after 3 days. So what? Just buy the new model that works with windows 12. Download a buggy new tool chain. The Z80 tools worked. The PDP8 was built to last. 50+ years and going strong. NOT the crappy PI PDP-8 or PDP-10. I give it 2 years max. Now a PI style computer with compact FLASH x 2, NO USB and 2 MEG ram , real serial and printer ports that will work in a noisy industrial setting, would be quite usefull. I'd pay even $3 for it. :)

Well my PDP-8 was built in 1974 and is still running (with careful maintenance).  My PiDP-8/I has been up and running continuously with a Raspberry PI 3B running it for about 5 years now.  My PiDP-11 has been up and running with a PI-4B for more than 4 years continuously. Though I agree with your comment that the PDP-8 was built to last (just ignore the disintegrated foam used between the motherboard and the case or on the case top) I have PCs that are more than 10 years old that are still running. As for the RP2040 being cheap crap, I beg to differ with you.  It is a solid chip, produced in 10s of millions at least.  And, I would bet, a better quality chip than your Z-80, if due only to improved IC manufacturing technologies. Just because it's old doesn't make it good.  I worked on a 32KHz 4 Bit CPU (about 20 years ago) where the development hardware was very unstable and the tool chain not a whole lot better. Early Microsoft and Lattice C compilers for the PC were buggy as hell.  If you want I can list a few bugs from each of them in another thread. One of the biggest features of the Z-80, the extra register set, was rarely used in open source software in order to maintain compatibility with the 8080. Some of the early Z-80 CP/M tools did not work because they were derived from 8080 tools.  After time the tools got better.  That is the case with any piece of software.  If it doesn't become obsolete and if maintained it will get better over time. On 4/21/2024 1:09 AM, ben via cctalk wrote:

Even the 6809 could push up to 8 registers (up to 10 bytes) at once on one of two stacks in a single two byte instruction. On 4/21/2024 11:27 AM, Chuck Guzis via cctalk wrote:

The 6809 was my fav 8 bitter to program. Relocatable code, many addressing modes, the index registers, stack pointers, consistent instruction set.. There was a decent C compiler, Introl. It's a shame that it never really caught on. I've often wondered whether the RCA 1802 could've been considered "RISC". Lots of registers (for the time). Simple instructions executing in 1 or 1.5 cycles if I recall. LoL, it even had a "SEX" instruction.. Cheers! On Sun, Apr 21, 2024 at 10:16:32AM -0700, Chuck Guzis via cctalk wrote: -- Bill Duncan, | http://billduncan.org/ bduncan(a)beachnet.org | - linux/unix/network/cloud +1 416 697-9315 | - performance engineering, SRE

Raspberry Pi and Raspberry Pico are entirely different and unrelated devices. I've been using the original Pico and also the Pico-W (with WiFi for one more dollar) for a bunch of projects; they work well and the price is hard to beat. The PIO (programmable state machine) subsystem is particularly impressive; for example, I used it to implement a DDCMP sync line interface. paul

On 2024-04-21 5:26 p.m., Chuck Guzis via cctalk wrote: Thru the hole and 5 volt and cheap and easy to find ( at one time ) and low edge rates , are important for me as I have kitchen table kind of projects. Before you say use XXX , I don't have the skills or the tools to layout and debug high tech boards or parts. I am very unlucky with FPGA stuff. My current bit slice computer design has some sort of dynamic problem, as only some instructions will run or read correctly. Halt and STOP don't work. Front panel works mostly. I need to rethink a whole new design,as something I can build and test and find parts for. The goal is a 20 bit word length computer, with 10 bit bytes,bit slices, Compact flash , UART's and blinking light front panel. I may run in emulation, until I can get hardware built and debugged but I have not found a host computer I like. So if any one wishes to take on this project, feel free using modern parts. Ben. * april 21 2024 sdc 1 Small Data Processor 1 .815 uS CYCLE TIME - BYTE BASED COMPUTER - INDEX REG'S - REGISTER OPS - CARRY BIT - AUTO/INDEX - LOGIC OPERATIONS - HEX FRONT PANEL MM 00 0 0 10 2 1 01 WRD wrd 11 SEX sx 5 4 3 2 1 +----+----+----+----+----+ |OOOO:AAAA|XXXX:B321|+###| NORMAL +----+----+----+----+----+ OP TC 0 ST SUB ADD 1 ADD ADD RAMU Z SUB 2 SUB SUB RAMU C SBR 3 CAD SBR RAMU S OR 4 LD OR AND 5 OR OR RAMD Z BIT 6 AND AND RAMD C XOR 7 XOR XOR RAMD S XNR F C 0 0 0... CF F C 0 0 1... UART i = index , 0 # CCC COND TRAP (0) <- PC PC <- 2 ADR LOAD N 0 H/Z ST 1 A LD RAMU Z 2 B ADD RAMU C 3 C(carry)SUB RAMU S 4 G OR 5 X AND RAMD Z 6 Y XOR RAMD C 7 F/F JMP RAMD S REG C is CARRY IR PC CTL 0 0 TEST 0 1 DSP 1 0 HLT 1 1 DI/EI ----------------------- M1 = a/m1 M2 = b/m2 M3 = idx ---- M3,M2,M1 ST OP 0 0 0 CTL OP # 0 8 bits 0 0 1 HLT SCC 1 0 1 0 ST R+ OP R+ 2 0 1 1 JSV R+2 JCC R+2 3 1 0 0 - REG 4 1 0 1 - SFT 5 1 1 0 ST @R+ OP @R+ 6 1 1 1 ST X ST X 7 ----------------------- '/' LINE COMMENT 'star' BLOCK COMMENT BEGIN/END ONLY #OOO OCTAL PROGRAM COUNTER ______________ | KROMA.PLD | CP x---|1 24|---x Vcc AD7 x---|2 23|---x WR AD6 x---|3 22|---x PRA0 AD5 x---|4 21|---x PRA1 AD4 x---|5 20|---x PRA2 AD3 x---|6 19|---x PRA3 AD2 x---|7 18|---x PRA4 AD1 x---|8 17|---x PRA5 AD0 x---|9 16|---x PRA6 AUX x---|10 15|---x PRA7 x---|11 14|---x M3 GND x---|12 13|---x CLR_ |______________| [II8,sft,no,ld,ra,m2,m1,op,w,WR] ______________ | KROMB.PLD | CP x---|1 24|---x Vcc AD7 x---|2 23|---x BY AD6 x---|3 22|---x PRB0 AD5 x---|4 21|---x PRB1 AD4 x---|5 20|---x PRB2 AD3 x---|6 19|---x PRB3 AD2 x---|7 18|---x PRB4 AD1 x---|8 17|---x PRB5 AD0 x---|9 16|---x PRB6 aux x---|10 15|---x PRB7 x---|11 14|---x RD GND x---|12 13|---x CLR_ |______________| [RD,ctl,rx,rd',in',ir,mar,rd,b,BY] OCTAL CPU FOR 20 BITS ( RUN,ST)(M3,M2,M1) (cnt 3,2,1) 7 6 5 4 3 2 1 0 * / TIMES ARE IN MICROSECONDS #100 / IDLE PANEL ALL 4 CLOCKS 3.26 AC SW MAR NO PC CTL PC IR #110 / LOAD ADR AC LD WRD PC LD WRD MAR / DON'T CARE TERM AC PC IR #120 / READ MEM -> AC AC WRD LD PC 1 Y MAR AC RD IN AC LD WRD IR #130 / WRITE MEM -> AC AC WRD LD PC 1 Y MAR AC WR RD PC IR #200 / QUICK # 2 CLOCKS 1.63 PC 1 Y MAR AC OP SX BY RD IR #210 / SCC 3 CLOCKS 2.45 PC 1 Y MAR AC CTL AC LD IR RD PC / MET CC AC SX LD IR RD #220 / R+ 4 CLOCKS 3.26 IX SX Y MAR AC RD IN BY PC 1 Y MAR AC WRD OP IR RD #230 / JCC R+ 4 CLOCKS 3.26 CONDITION NOT MET IX 1 Y MAR AC CTL SX RD IN // ADD CONSTANT PC 1 Y MAR PC IR RD / MET CC SW NO MAR / 6 CLOCKS 5.4 CONDITION MET PC CTL / DISPLAY AC PC PC LD WRD MAR PC 1 IR RD #240 / REG OP 4 CLOCKS 2.26 IX NO WR IN / put IX on the bus PC 1 Y MAR AC OP WRD IR RD #250 / SHIFT x 1 2 CLOCKS 1.63 PC 1 Y MAR AC SFT IR RD #260 / MEM @ R+ 4 CLOCKS 3.26 IX SX Y MAR AC RD IN PC NO LD WRD MAR AC RD IN BY PC 1 Y MAR AC OP WRD IR RD #270 / MEM X 6 CLOCKS 4.89 PC 1 Y MAR PC RD IN IX NO WRD MAR AC RD IN BY PC 1 Y MAR AC OP WRD IR RD / store ops #300 / DI 2 CLOCKS 1.63 PC 1 Y MAR SW CTL RD IR #302 /TRAP / pc -> 0 pc = 1 PC LD NO MAR SW CTL RD WR PC LD 1 MAR PC RD IN PC LD WRD MAR PC 1 RD IR #310 / hlt 2 CLOCKS 1.63 PC 1 Y MAR IX CTL RD IR #320 / ST # 4 CLOCKS 3.26 IX SX Y MAR AC RD WR BY PC 1 Y MAR AC IR RD #330 JSV R+ 6 CLOCKS 4.89 IX 2 Y MAR PC RD IN AC 1 SUB MAR PC WR RD PC LD WRD MAR PC 1 IR RD #340 / NOP PC 1 Y MAR PC RD IR #350 / NOP PC 1 Y MAR AC IR RD #360 / ST @ R+ IX SX Y MAR AC RD IN PC NO LD WRD MAR AC RD WR BY PC MAR PC 1 IR RD #370 / MEM X 6 CLOCKS 4.89 PC 1 Y MAR AC RD IN IX NO WRD MAR AC RD WR BY PC 1 Y MAR PC IR RD / ALL DONE $

While intention might have been to last XX years, I am becoming increasingly pessimistic about longevity of most electronic devices. A crystal radio with an open air capacitor seems like the only good bet. Between electrolytic capacitor aging challenges, discrete and integrated circuit hermetic failures, cost or other inherent technical flaws, I fear most electronics will become inert over time. Many of us have the skills to identify and replace bits to extend the lifetime of many items. I only hope the skills and suitable replacement parts are available as time goes on.

On 4/19/24 20:57, Bill Degnan via cctalk wrote: Rochester Electronics might buy up the masks and uncut wafers. That's their business model. Jon