A new year, a new (big) project: I decided to create a whole computer from transistors. Yes, individual transistors. There are of course many many projects like this on the web, but none of them are mine, so, challenge accepted. Plus, most of those machines are rather minimalistic designs, mostly owing to their tiny memories. I intend to build a much more capable machine:

1. 2MHz operating frequency
2. 32kByte of magnetic core memory
3. 16-bit data, address and instruction length
4. RISC-like instruction set but multi-cycle implementation
5. Interrupt capability and peripherals

This time around I decided to document the project as I go, not as a postmortem. If this sounds interesting, check the details out here:

The Disintegrated Machine

Welcome to the glorious new year!

As the first post of the year, let me spin you a short story on a computer from a foreign land. In more than one sense. As L.P. Hartley observed, “the past is a foreign country”, and indeed, this particular machine is from the ’80s. Also, this machine originates from the UK, quite ways away from my current home. Not so much from my childhood though in either of the senses: it was one of the ‘elite’ class machines that I drooled over in shop windows as kid, never being able to afford it.

Enterprise 128 (source: Wikipedia)

It was a really nice, Z80-based home computer of the day with advanced graphics and audio capabilities (even compared to my Commodore 64). It also had 128kB of RAM.

As I completed my work on the Z80 core for the UnIC project, I was casting out for more than my initial PCW512 machine as a test subject. I came across this one on eBay and my old fascination got re-kindled.

Soon, the specimen showed up at my doorstep, straight from Cairo, and in a condition that I would assume a machine repeatedly exposed to the fertile yearly floods of the Nile would be in. After some furious scrubbing, it regained its original shape and color, so I turned it on, and … nothing. I verified the power supplies, the reset and the clocks, all were fine, yet, no boot. Poking at the signals, I’ve seen that many of the controls of the processor (nRD, nWR, nIORQ etc.) were showing strange behavior: nice high levels, but rather inconsistent, erratic lows. This could be caused by two things: either the source (the Z80 processor) has faulty drivers and can’t drive the lines properly or the sink has faulty inputs and load down the signals too much. This was bad news indeed. You see, this particular computer was built around a pair of ASICs (called Nick and Dave after their designers); if either of those were damaged, it would be game over; they are irreplaceable short of getting another machine. Even then, being surface mounted affairs, they would be difficult. Still, there’s only one way to find out: replacing the Z80. The CPU on the motherboard was soldered in, so it took some effort to get it out, get a socket in and a replacement CPU (temporarily liberated from my XZ81) in said socket. Power up and boom! Or, rather, boot! It was a close one, but I got lucky: it was the CPU that kicked the dust.

Next I had to replace the keyboard membrane which was in unconscionable condition. Luckily, someone makes brand new replacements. Unluckily (but unsurprisingly), they are in the UK. Another long wait ensued after which I managed to get to the next step: realizing that the machine doesn’t have a BASIC interpreter built in; for that one needs a ROM cartridge, which the seller conveniently didn’t include. I also realized that the machine I got was the 64kByte RAM model, not the more popular (and useful) 128k one. Which finally gets me to the meat of this post: I re-created both boards.

The ROM cartridge

This is a very simple affair: the computer exposes a 16-bit address bus and an 8-bit data bus on the cartridge port with all the requisite control signals. One just have to directly hook them up to a ROM chip. The total addressable ROM space is 64k – as you can convince yourself by some math-ing – but I decided to include support for chips up to 4Mbit (512kByte). The reason for that is mostly why not, but also because they are still manufactured and cheap.

The remaining address pins are connected to jumpers:

Yet another jumper is provided to support re-flashing (the old days of EPROMs are long past, all these chips are single-supply, 5V programmable FLASH devices). Not that it’s useful without someone writing some re-flashing utility, which I won’t. It’s also quite possible that the chip-select is connected incorrectly and would need to be hooked up to pin B4 instead of B3 if writes are needed; again something that’s very hard to test without going the whole way of trying to flash the parts in-situ.

Sponsored content

The board was manufactured by PCBWay with their usual high quality and speed. In case you didn’t know, they make affordable PCB prototypes and ship them to your doorstep. Not only that, but they can do PCBa assembly, 3D printing, even injection molding or CNC machining if that’s your fancy. If you are reading these pages, chances are you are a tinkerer just as I am. You should check them out! The boards (as evidenced by the pictures) are of high quality, though I have to say: these designs should not stress the manufacturing capabilities of any supplier. One thing of note: the ROM board uses immersion gold as a surface finish. This is useful for edge connectors as it is much more corrosion-resistant then other finishes. It makes the board more expensive and slower to manufacture though. Immersion gold however is softer than the best option (hard gold finish). That means faster contact degradation during multiple insertion/removal cycles, something that a ROM cartridge would potentially be exposed to. Still, hard gold finish is much much expensive, so I did not choose that. Here’s the best part: I learned this from PCBWays own web-site. I honestly say that their knowledge base database is one of the best ways to learn about the ins and outs of PCB manufacturing.

Putting the board together wasn’t a big deal. Even from the schematic, it should be obvious, how simple this thing really is:

A more complicated question is how to get the content into the FLASH device. I went back to an old trick I’ve used to rescue an old ISA motherboard that lacked a BIOS: use an Ethernet card with a BIOS expansion socket and an old DOS utility that supported said Ethernet card. With that, I had all the pieces in place as far as ROM was concerned.

The RAM expanded

The second project was to create a memory expander board for my Enterprise. There were several old designs on the web ranging in capacity from 64k (bringing the total up to 128k) to 256k or even 512k. These designs all still used DRAM chips, something that would be next to impossible to track down these days, new at least. So, I adopted a different approach and used a more modern 512kByte SRAM chip instead. These are also dying out in their 5V incarnation, but some are still manufactured. Since these don’t need to be pre-programmed, I opted for a surface-mount design which makes the board much more compact. The schematic is slightly more complicated, but only slightly:

The reason for the complication is that – for this particular internal connector – the whole 22-bit address bus is exposed, so address decoding needs to be implemented. Not only that, but full address decoding is required, otherwise the operating system (EXOS) will detect the incorrect RAM amount. Finally, I wanted to make it possible to select (through jumpers) the amount of RAM exposed to the system. This serves two purposes: The original 128k model has a very specific place in memory for the second 64k, one where there is room for only 64k. If there are programs out there that depend on the physical address of RAM instead of querying the OS for it or detecting it themselves, those would be incompatible with anything other than the base 128k model. The second is that the memory size detection code is rather slow: the more memory you add to the system, the slower it boots.

The PCB was manufactured by PCBWay as well and, after assembly has the following resemblance:

The shape of the pads around U2 might need some explanation: this particular package comes in several length variants. All compatible, except one longer than the other. I elongated one set of pads to accommodate the whole range.

The original design connected the equivalent of this board to the main motherboard though a set of wires instead of board-to-bard connectors. I opted for simple headers instead: the sockets needs to be soldered in to the motherboard, the headers into the RAM board. That way they can part ways whenever I chose to without the involvement of a soldering iron and some choice words. Little did I know that the holes in the motherboard are too small to really fit the pins and the two rows are ever-so-slightly further apart than the standard 100mil as well. Some blunt force still convinced the socket to it in the holes, but that was a not-so-pleasant surprise:

After that though, the board fit nicely. As an extra benefit, it doesn’t cover the Nick chip, which needs a heat-sink (not shown here). This way cooling is going to be more efficient.

The moment of truth

Both cards being completed, FLASH programmed, I turned the machine on. Did it work? No, not at first. There was one bodge-wire that was needed on the ROM board and I screwed up the default-inversion of A19 on the RAM board which needs the inverse application of the first jumper. Both of these mistakes are corrected in the schematics shown above, but they did slow me down in the bring-up process. After realizing and fixing both mistakes though:

Ta-da!

If you want to replicate any of these projects yourselves, you can find them on GitHub:

• https://github.com/andrastantos/enterprise_cartridge
• https://github.com/andrastantos/enterprise_mem_extender

Enterprising with UnIC

I mentioned my UnIC project at the beginning. That is what’s called foreshadowing. I went through all of this to get a second test platform for my Z80 core. Now, with a BASIC interpreter in place, a socketed CPU and a working keyboard, it should be easy to test it out. So I did. And did it work? No. No, it didn’t. The initial memory test passed, but then a blank screen and an eventual reset followed instead of the colorful welcome screen. I guess, this is what I get for trying to be thorough. I will have to whip out my trusted shadow tracer and hunt for further differences between implementations. That however is a story for another day.

Coda

After finishing this document and the project, it was time to put the machine back together. That’s when I realized that my fancy memory expander board interferes with the top cover of the machine. I was careful enough to design the PCB to be flexible for such an occasion: I had a secondary connector for the 10-pin header, one that can be used with a ribbon cable. I needed to solder the cable into the motherboard (yes, the case design doesn’t allow for any connector there). My board at least still can have a connector, it can still be easily removed, if needed. I also had to saw off sections of the board that were interfering:

It looks much less professional now, but, it still works. And I can close the case too!

I have to say though: I’m really disappointed with the attention to detail that went into the engineering of the PCB. Why have two connectors for the memory expansion? If you must, why have them so close to the board edge? Why have them such that no standard headers fit in them? Why not make them so that the expansion board can be mounted as a mezzanine design on top of the motherboard, using headers? Why make it so that any non-wire-based design would surely interfere with the case design?

The Xmas break gave me the opportunity to work some more on the UnIC project and its off-shoot: the Z80 processor replacement. Hopefully in the last chapter of this process, I’m describing how I tracked down the last couple of discrepancies between my (T80-based) implementation and the Z80 processor.

The project was sponsored by PCBWay, who provided PCB manufacturing services for the synchronizer board I’ve used to create the environment for the experiments.

I’m looking forward for the new year and new, exciting things to do with UnIC. Stay tuned for that and until then: happy new year!

The UnIC project arrived at a major milestone: after some inordinate amount of work, I managed to track down the last remaining (known) problem with the FPGA code for the Z80 emulation.

There were two pieces to this puzzle: the Shadow Tracer board and FPGA core that allowed me to quickly identify discrepancies between the Z80 original and my (well, T80-based, so it really is a community effort) implementation.

This really simple PCB allows for parallel execution of both designs while comparing and flagging any differences:

The PCB was manufactured by my sponsor, PCBWay. They did a great job on making the boards for me quickly and in high quality. They also can do all sorts of other jobs, such as PCB assembly, flex or rigid-flex PCB manufacturing, even 3D printing and injection molding. I haven’t used those services yet, but it if that is what you need, give them a visit!

The second part was doggedly going after the problems as they arose until I was left with the true issue: a bug in the T80 NMI handling that allowed for a nasty priority-inversion and a loss of an NMI event.

I’m a bit cautious about opening the champagne bottle yet though. I want to build yet another board, one that would hopefully allow to truly check for all remaining differences:

I suspect it will uncover some discrepancies, hopefully nothing major. But, for the first time in this long project, I am at a point where I’m not aware of any issues. Let me tell you, it feels nice!

If you followed my recent posts, you are probably aware of the UnIC project. This is a small FPGA-based board that fits into a 40-pin DIP socket and through some clever techniques can emulate almost any TTL or CMOS, 40-pin packaged device from the past. As a first real application, I’m making it into a replacement of the venerable Z80 processor since it has recently been discontinued.

The FPGA in question has built-in FLASH storage, but nevertheless: every FPGA needs programming. They commonly use JTAG for this purpose, even if only to download the FLASH content for subsequent boots. To make UnIC do anything, I needed a JTAG programmer.

There are many of these, in fact I have designed and built several in the past myself. Modern ones, at least modern ones with a reasonable price-tag, almost exclusively use some sort of USB interface chip from FTDI. Previously the FT2232D was in vogue, these days the much faster FT2232H is a favorite.

UnIC itself has two ways to gain physical access to the JTAG port of the FPGA: it has a 12-pin, 1.27mm pitch header and a flat (FPC) cable connector. The former has the problem that – when populated – interferes with the optional OLED screen. The good thing about this header configuration though is, I already have a programmer from the past that I could use. This also helped getting started quickly: I knew the programmer worked, I only needed to get UnIC going.

The other interface, the FPC one, has a number of connections. As I mentioned, it provides access to JTAG, but also to several otherwise unused FPGA pins. These pins are useful to add extra interfaces to a project, but they can also be very useful during bringup: one can expose internal logic signals that can elucidate the inner workings of the circuit, or be used as trigger sources for hard-to-identify events.

So, the idea for this project was: create a JTAG programmer to attach to this FPC interface.

The design process

While I’ve been toying with this idea for a long time, I have not started seriously consider it until I was ready to release Shadow Tracer to manufacturing. I thought, why not combine the two projects and save on shipping?

As I said, I have designed several similar JTAG programmers in the past, so I thought, it should be easy. I took one of my earlier designs and ported it over to KiCAD as a starting point. This porting was rather smooth as KiCAD already had a pretty competent importer for Altium projects. One trouble arose though: KiCAD mandates that all reference designators end with a number, something that I didn’t do in my Altium-based design. As a consequence KiCAD insisted on re-annotating the schematic losing all connection between the the schematic symbols and their associated footprints along the way. Not a huge deal in this case, but I fixed up KiCAD to be better about this. The change has been rather simple and hopefully be part of the next dot-release of the project. At any rate, it solved my immediate problems.

Then, I needed to change a few things:

1. I changed the connector from a micro-USB to a USB-C one to go with the times.
2. I changed the ESD diodes to something that’s easier to solder
3. I replaced hard-to-work-with resistor packs with individual 0603 resistors.
4. I updated almost all footprints to the equivalent ones from the standard KiCAD library.
5. My old design used a MAX-V CPLD for level-shifting purposes (it is very cheap), but I didn’t want to deal with yet another JTAG programming project just to get my JTAG programmer off the ground. So I replaced that with a set of dedicated level shifters
6. I replaced the target connector with the FPC one
7. I added an extra connector to break out all FPC connector pins for easy probing
8. I added test-points to some otherwise unused pins on the FTDI chip, the idea being that these could be used for extra control or status capture.
9. I simplified the LDO design and – especially – the level shifter supply design.

The level shifters and the LDO need a little explanation: the FPGA in question on UnIC is a 3.3V I/O device, at least the way I have it hooked up. The FTDI chip can directly talk 3.3V. So, technically no level-shifter is needed. The problem though with the FTDI chips in general is that they ‘wiggle’ their pins during enumeration. This can confuse attached devices down-stream, such as my FPGA. To be safe, an isolator of sorts is needed. Luckily there is a pin exposed on the FTDI chip (they call it “power down”, but whatever) that can be used for controlling said isolators. If isolators are needed anyway, one might as well as use a level-shifter for the purpose. Now, the other design decision in the old project was to use a follower-regulator for the target-side power supply. This allowed for not loading down the target and also to support 5V targets with only 3.3V I/Os. None of this complexity is needed here: the target is fixed at 3.3V.

The main LDO I’ve used is an old – and strange – one. It has it’s heat-sink connection attached to its output, not to the more customary GND. I contemplated moving away from this chip, but decided against it in the last minute: I had some of these LDOs already in my drawer and in fact the VCC connection worked out better on the PCB: I had a VCC fill on the top layer anyway, so attaching to it was better then adding another (GND-connected) fill just for the purposes of the regulator.

As you can see the change list is actually rather extensive. Add the change in form-factor and you can see how a new PCB design was in store. Yes, the general idea and concepts didn’t change from the old design all that much, but that doesn’t help when footprints change.

A word from our sponsor

With all that though, I managed to finish the design in a day or so. It’s not a complex one and – as I have said – I am familiar with it. Off to PCBWay it went. They are sponsoring my work by offering free manufacturing services. The boards arrived very quickly and with the usual high manufacturing quality. In case you are looking for PCB services, check them out! Even if you don’t need a PCB, you should as they offer more than just PCB manufacturing: PCBA assembly, 3D printing, flex and rigid-flex PCBs, injection molding among other services. They truly are a one-stop shop for almost any manufacturing need.

The troubles start

My troubles started even before I had the PCBs in my hand: when ordering the parts, I realized that one of the level-shifters I’ve designed in was end-of-lifed by the manufacturer. Not a huge deal, Digikey still had a few in stock, but still poor form for a new design. I also haven’t been able to find a pin-compatible replacement, so if I was ever to build more than a couple of these a redesign is going to be needed.

When the PCBs and the components showed up, I could put the board together. The assembly was rather uneventful, my changing into more hand-assembly-friendly packages paid off. The only exception to this was the FPC connector: this was a major pain in the rear to work with.

I decided not to even attempt to use solder wire and opted for a very low-temperature solder paste. The benefit of this particular paste is that with its very low melting point it can be surgically applied and subsequently melted with a heat-gun without worrying about adjacent solder joints (done with a higher temperature solder) getting re-melted. This makes selective work and re-work much easier. A second benefit in this particular case is that I didn’t have to set the temperature of the gun to a point where it would melt the otherwise easily damaged plastic parts of the FPC connector. Still, with all that, the pads are tiny, they are almost completely underneath the connector and the tolerances are frightful.

The other problem was the LDO: when updating the packages, I’ve used an incorrect one: the actual part is smaller then the footprint. Thanks to the fill for the heat-sink, it can still be put in place, just had to scrape off some of the solder mask. Ugly, but functional.

Then, it was time to plug the contraption into a PC. And… nothing. I at the very least expected the FTDI chip to enumerate. But it didn’t. The troubleshooting in these instances follow a familiar pattern: check connectivity, check power, check clocks, check reset. Connectivity is easy to check, no issues there. Power? Not so great: the main 3.3V LDO is unstable. I said, it was an old design; I’ve used this regulator before:

I did change the way I used it in this design though. After checking the datasheet, I decided to get rid of the resistor in series with the output capacitor (R12): this was something I really didn’t like about it and it seemed the part actually doesn’t need it. In retrospect, it was a mistake. The LDO is not stable without it, and now – with the footprint removed – it’s a pain in the rear to hack it back in. Parallel is easy: it just needs to be bolted on top, but series is hard: you need an extra node on the board somehow. The result is really ugly:

But at least it worked and it stabilized the LDO. Yet, not improvements: still no enumeration. The core voltage – generated by an internal regulator in the FT2232H was rock solid, so I moved on to clocks. To my astonishment, there was no clock! Well, no wonder it won’t enumerate then. But why weren’t there any clocks? The clock circuit is simple to the point of being trivial:

Did I screw up the crystal selection? Nope. Did I screw up the capacitor selection? Yes, indeed, I did. Wrong values! Changing them to the right ones (luckily I had them) didn’t change the behavior. However, I did notice that during power-up, the oscillator briefly comes to life, but then shuts down again. This indicates some signs of life, in fact it indicates that something shuts the oscillator down. This is new, I haven’t seen this before from any of the FTDI chips I’ve worked with.

So what gives? Is there something shorted? Does the core get into some over-current condition? Is it that the core voltage drops too low and browns out the controller? Or same for the I/O? No, no, no, no and no. None of these seemed to be happening. In desperation, I started de-soldering components that weren’t crucial to enumeration: the level shifters, the EEPROM, pull-ups and downs; nothing.

As a last resort, I removed the ESD diode from the USB wires:

After that, finally, the USB connection come up and my PC enumerated the FTDI part. So, it was the ESD diode. But why?! I didn’t have it in backwards. It is 5V rated and it seemed not to impede the D+ and D- lines going up and down. It’s quite possible that it has too much capacitance (320pF) for a high-speed USB 2.0 connection. Maybe. I didn’t investigate too hard. I was too tired of this hunt. Off the board it went I moved on with the bring-up.

More troubles

Now with the FTDI chip enumerating, I could concentrate on the target side of things.

Something I realized even before the boards came back was the lack of de-coupling capacitors on the target-side voltage domain of the level shifters. It wasn’t terribly hard to add them, but they had to go on the back-side of the PCB: that was where the right traces were exposed in convenient locations.

I connected the target over the thin FPC and… again, nothing. I couldn’t even read the ID from the FPGA. Back to hunting problems, I relatively quickly zeroed in on the FPC connector. This is not something that’s terribly easy to ‘beep’ out; the connections are very tight. The aforementioned break-out helped on one side and plugging and actual FPC with the other end exposed helped on the other. It turned out the terminals had a number of shorts. These must have been under the connector as they were not visible form the outside. I removed the connector and tried a new one (without applying any more solder paste this time). Now, all the shorts were gone, which was great news. They were replaced by a number of opens, which was not. Frenetic soldering iron action ensued. Ungodly amounts of flux later I eventually got all the connections working. I certainly wasn’t amused and not looking forward for a repeat experience.

Conclusions

Eventually I did get the board working. It is still a good citizen of my ever-spreading setup for UnIC development work:

In that sense the project was an (eventual) success. I would not call it model to follow by any means though. It was plagued by several design flaws, mistakes and rushed decisions that all came back to bite me later on. I’m not proud of this project and I post it as a cautionary tale rather then a boast: don’t follow my footsteps; check your work prior to sending it to manufacturing and always, always be on the lookout for ‘just a small change’. Those are the easiest to get wrong. Five of the nine changes I listed at the top resulted in problems I needed to deal with in one form or another.

This is a project, that I’ve been working on and – on and off – documenting on this website for a while now. With the first form-factor build in my hands and testing to being, it deserves the top spot on the page.

This work aims at replacing (almost) any 40-pin DIP package chip from the yore for which manufacturing has stopped and is not available anymore. It is based on an FPGA, so it can emulate digital designs, but otherwise rather universal. It can operate from anything between 5 and 12V, it can take power on any pins in any combination, as long as no negative supplies are present.

As the first application of this technology, I’ve ported the T80 processor (a Z80 replacement written in VHDL) onto this platform, aiming it as a drop-in replacement for the venerable Z80 that was recently discontinued.

It is still work in progress, there are still bugs to iron out, but there is promise: UnIC can boot into CP/M, execute Batman, LocoScript, even boot and run SymbOS on a PCW8256:

The project is sponsored (i.e. I got a discount from them on the manufacturing of the PCB and assembly costs) by PCBWay. As you might have guessed, they are a company making a living by making PCBs for you. That being said, they do a lot of other things, such as 3D printing, injection molding or even CNC machining. If you need things to be made, they are an option. You should check them out!

Intro

Let’s get something out of the way at the top: this is a sponsored post. PCBWay asked me if I wanted to write something up in celebration of their 10 year anniversary. That being said, while the subject wasn’t my idea, the content is, and I stand by it: I’m not writing anything that I don’t believe to be true and correct. Now, to the meat of the post:

PCBWay as you may know already and probably guessed it from their name is a company that makes – wait for it – PCBs. They are located in China, like many many of their competitors. However, what differentiates them from some that I’ve worked with in the past is their vast array of additional services they provide. On top of PCB manufacturing, they do PCBA assembly, can make stencils for you, create housing and other mechanical components using 3D printing, injection molding, CNC machining or sheet metal processing techniques. Even just within PCB manufacturing, they offer rigid, rigid-flex and flex PCBs with many many options ranging from simple single-layer affairs to 64 layers and God knows how many lamination cycles. They offer all sorts of mechanical and laser vias, base materials, and finishes. In short, they can do anything I can afford and lot that I can’t.

Review

My experience with them so far has been through two projects: one was a relatively straightforward 2-layer PCB project. I’ve used KiCAD for creating the design. The submission process was straightforward. Communication from both of their sale and DFN teams was prompt and efficient. We worked through the flagged issues (either fixing or waiving them) and the design went into production. Even though I opted for the slowest (cheapest) option, the boards got made in a couple of days and delivered all the way to my doorstep in only a few more. End-to-end it might have taken 10 days? Maybe even less. It certainly took less time then for DigiKey to ship me the components. The quality of the PCBs was also good. Granted, this is not top-of-the-difficulty-scale stuff, but still, nothing to complain about there.

For my second and most recent project with them, I went for something more ambitious. Not only I upped the PCB layer count to 4 (still nothing crazy, only through vias and no impedance-control), but I also tried out their assembly service. Since this is my first time contracting assembly, I don’t have a comparison. Here’s my experience though: the submission process was a bit more involved, needing to generate pick-and-place files as well as a BOM. PCBWay provides a KiCAD plugin to make that process easier, but it didn’t do what I wanted and even worse, it automatically submitted the generated files without giving me an option to review. Your mileage my vary. On that front, I wasn’t terribly impressed, but at least it gave me a starting point to improve from.

Once I had the design files ready, I could upload them to the website. Soon, I got contacted by their team and the fine-tuning of the BOM started. I’ve opted for a ‘turnkey’ solution, where PCBWay was going to buy the components. The reasoning was that it was easier for me and probably cheaper too as most of the components I was using are generic. They probably already had most of them in stock. While I was right on most accounts, there were a couple of exceptions: the LED I picked for instance they didn’t have, so we had a little back-and-forth about finding a suitable alternative. Normal, expected.

Then there was the big sticking point: the FPGA I was using. This is something that not too many distributors carry. I was hoping that PCBWay can get the components direct from the manufacturer (both being Chinese), but that fell apart. The manufacturer (or rather their representative) and PCBWay couldn’t agree on the shipping terms which would have resulted the parts getting shipped from China to me here in the US, then back to China for assembly, then, finally back again, assembled. Not only crazy, but expensive both for shipping and tariffs. I would have also had to fill-out all sorts of serious-looking forms (import/export declarations, shipping details) that I knew next to nothing about. Not saying it was PCBWays fault, but I am saying that this was frustrating. The end result was that I decided to manually mount these components myself and released the assembly process with PCBWay with that particular part unpopulated.

From there on, the process was rather smooth, but much longer than a simple PCB order. It took several weeks for them to collect all the components and get ready for the build. What I did like was the communication. I got regular updates of where the project was, they even did a first-article build and sent me several pictures (normal and microscopic) to ensure the components are the way the should be. Here’s one of them:

Once the boards got made, the crazy fast shipping was a great plus yet again.

Outro

While I was looking at cost-reduction options, I came across their page describing the PCB process. I really liked this description of how a PCB gets made complete with short videos and detailed description of each step. If nothing else, its a great learning tool. They have a similar page, albeit not as detailed on their assembly process.

I guess this goes into the good communication bucket, but this kind of material really increases my trust in the company.

PCBWay also has a projects page. This is a location for customer-submitted content. Videos, projects, tutorials. There’s a lot of material there and I’ve noticed some projects that I’ve learned of though other means to pop up there as well. For example the Gremlin HDMI video card, an awesome project indeed. I guess the idea here is that you can order the PCBs and potentially the assembled device from PCBWay directly, driving more business to them. It – presumably – also increases the visibility of the projects. You of course don’t have to use their services: you can download the design files and shop around or just go to your preferred fab. Or order from the owner/creator.

I myself have not contributed projects there, but maybe I will in the future.

So, PCBWay is turning 10. They have been a good partner for me, I was satisfied with what they provide and will use them in the future.

I have a few projects in the works. They build on one another, so it’ll take a while to publish all the pieces that go with them. The first, and relatively stand-alone piece is the UnIC project.

I quite proud of this idea, though it’s not one of those Earth-shattering break-throughs that people will talk about for millennia. It’s a circuit that can replace any (well, almost any) 40-pin DIP package chip, if the FPGA on it is programmed the right way.

The trick is not the FPGA or even the 40-pin DIP form-factor; there are several projects around that fit the bill. The trick is that the UnIC design is not only universal in its logic capabilities, but its power requirements as well. It doesn’t care which pins are ground and which are power. It doesn’t even care if there are multiple (positive) supplies, or if there’s a – say – +12V supply on the package. It just takes it and works with it.

Right now you can find the following pages on this project:

1. The introduction page with a detailed description of the operation of the circuit
2. A story about the first prototype by PCBWay; the build and testing process
3. A story about debugging a regulator problem
4. My escapades in making a Z80 replacement using the UnIC design
5. Further adventures in Z80 land
6. Shadow tracer: how to find subtle differences between two Z80 implementations
7. Finding a nasty priority-inversion problem preventing CP/M from working
8. How to make asynchronous events synchronous and finding the last few differences

Yes, this is a sponsored post. I’m not going to be bashful about it, in fact I’m proud! I have a sponsor: it’s PCBWay. They – as you have guessed I’m sure – make PCBs. From quick-turn, low volume prototyping to small(ish) production runs.

Their support includes the usual 2-layer affair, but multi-layer and rigid-flex designs aren’t beyond their capabilities. They can manufacture buried and blind vias, even laser-vias if that’s what you fancy.

Pretty nice, but just that wouldn’t be all that outstanding: there are many companies doing that. PCBWay however also do CNC machining, 3D printing, make SMT stencils for you, even buy and put the components on your circuit boards.

In one word: they are your one-stop prototyping shop. They are mine.

The other day I felt nostalgic and wondered over to the great archive.org site, originally to look for Commodore 64 material. Then, I thought, what the hell! and typed ‘cray’ into the search box. Lo and behold, a lot of hits! There are manuals, a CD image with some marketing or teaching material on it, but among them, two interesting CD images:

• https://archive.org/details/cray-cd1
• https://archive.org/details/cray-cd2

Both are UNICOS install images. I’ll have to see if they are complete and what version (and for what machine) they are, but I wanted to share the news: it appears that there is now a publicly available OS image (maybe even two) for my simulator.