Tiny Tapout is an interesting project, leveraging the power of cloud computing and collaborative purchasing to make the mysterious art of IC design more accessible for hardware hackers. [Yeo Kheng Meng] is one such hacker, and they have produced their very first custom IC for use with their retrocomputing efforts. As they lament, they left it a little late for the shuttle run submission deadline, so they came up with a very simple project with the equivalent behaviour of the Covox Speech Thing, which is just a basic R-2R ladder DAC hanging from a PC parallel port.

The plan was to capture an 8-bit input bus and compare it against a free-running counter. If the input value is larger than the counter, the output goes high; otherwise, it goes low. This produces a PWM waveform representing the input value. Following the digital output with an RC low-pass filter will generate an analogue representation. It’s all very simple stuff. A few details to contend with are specific to Tiny Tapout, such as taking note of the enable and global resets. These are passed down from the chip-level wrapper to indicate when your design has control of the physical IOs and is selected for operation. [Yeo] noticed that the GitHub post-synthesis simulation failed due to not taking note of the reset condition and initialising those pesky flip-flops.

After throwing the design down onto a Mimas A7 Artix 7 FPGA board for a quick test, data sent from a parallel port-connected PC popped out as a PWM waveform as expected, and some test audio could be played. Whilst it may be true that you don’t have to prototype on an FPGA, and some would argue that it’s a lot of extra effort for many cases, without a good quality graphical simulation and robust testbench, you’re practically working blind. And that’s not how working chips get made.

If you want to read into Tiny Tapeout some more, then we’ve a quick guide for that. Or, perhaps hear it direct from the team instead?

While we aren’t typically put off by a large wristwatch, we were taken a bit aback by [Chris Fenton]’s latest timepiece — if you can call it that. It’s actually a 1/25th-scale Cray C90 worn as a wristwatch. The whole thing started with [Chris] trying to build a Cray in Verilog. He started with a Cray-1 but then moved to a Cray X-MP, which is essentially a Cray-1 with two extra address bits. Then he expanded it to 32 bits, which makes it a Cray Y-MP/C90/J90 core. As he puts it, “If you wanted something practical, go read someone else’s blog.”

The watch emulates a Cray C916 and uses a round OLED display on the top. While the move from 22 to 32 address bits sounds outdated, keep in mind the Cray addresses 64-bit words exclusively, so we’re talking access to 32 gigabytes of memory. The hardware consists of an off-the-shelf FPGA board and a Teensy microcontroller to handle mundane tasks like driving the OLED display and booting the main CPU. Interestingly, the actual Cray 1A used Data General computers for a similar task.

Of course, any supercomputer needs a super program, so [Chris] uses the screen to display a full simulation of Jupiter and 63 of its moons. The Cray excels at programs like this because of its vector processing abilities. The whole program is 127 words long and sustains 40 MFLOPs. Of course, that means to read the current time, you need to know where Jupiter’s moons are at all times so you can match it with the display. He did warn us this would not be practical.

While the Cray wouldn’t qualify as a supercomputer today, we love learning about what was state-of-the-art not that long ago. Cray was named, of course, after [Seymour Cray] who had earlier designed the Univac 1103, several iconic CDC computers, and the Cray computers, of course.

There’s a good few options for exporting data out of FPGAs, like Ethernet, USB2, or USB3. Many FPGAs have a HDMI (or rather, sparkling DVI) port as well, and [Steve Markgraf] brings us the hsdaoh project — High-Speed Data Acquisition Over HDMI, using USB3 capture cards based on the Macrosilicon MS2130 chipset to get the data from the FPGA right to your PC.

Current FPGA-side implementation is designed for Sipeed Tang chips and the GOWIN toolchain, but it should be portable to an open-source toolchain in the future. Make sure you’re using a USB3 capture card with a MS2130 chipset, load the test code into your FPGA, run the userspace capture side, and you’re ready to add this interface to your FPGA project! It’s well worth it, too – during testing, [Steve] has got data transfer speeds up to 180 MB/s, without the USB3 complexity.

As a test, [Steve] shows us an RX-only SDR project using this interface, with respectable amounts of bandwidth. The presentation goes a fair bit into the low-level details of the protocol, from HDMI fundamentals, to manipulating the MS2130 registers in a way that disables all video conversion; do watch the recording, or at least skim the slides! Oh, and if you don’t own a capture card yet, you really should, as it makes for a wonderful Raspberry Pi hacking companion in times of need.

At one point, the Motorola 6809 seemed like a great CPU. At the time it was a modern 8-bit CPU and was capable of hosting position-independent code and re-entrant code. Sure, it was pricey back in 1981 (about four times the price of a Z80), but it did boast many features. However, the price probably prevented it from being in more computers. There were a handful, including the Radio Shack Color Computer, but for the most part, the cheaper Z80 and the even cheaper 6502 ruled the roost. Thanks to the [turbo9team], however, you can now host one of these CPUs — maybe even a better version — in an FPGA using Verilog.

The CPU may be old-fashioned on the outside, but inside, it is a pipeline architecture with a standard Wishbone bus to incorporate other cores to add peripherals. The GitHub page explains that while the 6809 is technically CISC, it’s so simple that it’s possible to translate to a RISC-like architecture internally. There are also a few enhanced instructions not present on the 6809.

In addition to the source code, you’ll find a thesis and some presentations about the CPU in the repository. While the 6809 might not be the most modern choice, it has the advantage of having plenty of development tools available and is easy enough to learn. Code for the 6800 should run on it, too.

Even using through-hole parts, you can make a 6809 computer fit in a tiny space.You can also break out a breadboard.

[Greg] has been working with the Tang Nano 9K FPGA board. He wanted to use the Gowin Analysis Oscilloscope (GAO) to build an internal monitor into the device for probing internal points. The problem is that the documentation is a bit lacking, so he made a video showing how to make it work to help us all out.

The idea for this isn’t unique, although for some vendors, getting this capability requires you to buy a license or the free versions are limited. We were disappointed, as was [Greg], that he had to run Windows to get the software to work.

The software seems capable, although we were interested in how much of the chip’s resources the integrated logic analyzer uses. We know from experience that being able to have a bird’s eye view of the signals inside the FPGA greatly simplifies debugging.

The Tang boards contain GWIN-1 FPGAs with different gate counts. We assume this software will work with any of the devices, regardless of the size. We’d love to know how to make this work on Linux, even if it takes a VM or WINE. In addition, the program has a number of options and features that either don’t work or aren’t clear what they are supposed to do. If you have any insight on any of this, be sure to share it with [Greg] and the rest of us.

We’ve rolled our own version of this that is portable. We’ve looked at this FPGA before and it is dirt cheap.