Homebrew 68K Machine Has A PCI Bus

The Peripheral Component Interconnect (PCI) bus was first introduced all the way back in 1992. It quickly became the standard way to interface add-on cards on the PC platform, supplanting earlier buses like ISA and various other oddball standards. You wouldn’t expect to see a PCI bus on a Motorola-based machine, but [maniek86]’s homebrew rig offers just that. 

That’s a lot of soldering.

This computer is a beautiful piece of homebrew engineering, constructed out of protoboard and loose wires rather than any fancy PCB. At the heart of the build lies a Motorola 68000 running at 10 MHz. It’s got 1 MB of SRAM, 4 KB of ROM, and a MC68681P acting as a UART, timer source, and I/O controller. Where things get special, though, is in the inclusion of a Xilinx Spartan II FPGA (XC2S100), which acts as a PCI bridge. It provides the machine with two 32-bit 5-volt PCI slots which are interrupt capable, albeit with no bus mastering. A XC95144XL CPLD also sits present to act as glue logic to help lace everything together.

[maniek86] does a great job of explaining exactly why the PCI bus was hard to implement, and how it was pulled off in the end. The guide also covers how the system was able to interface various cards, from a PCI serial expansion to a Cirrus VGA adapter. It’s all good stuff.

We’ve featured other work from [maniek86] before, too, like this brilliant 486-based single-board computer. Video after the break.

Continue reading “Homebrew 68K Machine Has A PCI Bus”

Performance Improvements For Open-Source 80386

The Intel 80386 is a rather fascinating slice of computer history. It marked the first 32 bit X86 processor, and was a staple of early desktop computing. Like all chips, it has a number of quirks, one of which being the fact that all commands are executed in microcode. By this nature, it was a rather excellent prospect to be re-implemented in an FPGA core called the z386. However, it was lacking a feature native to the original 386, early start memory access. So to bring some performance to the z386 project, [nand2mario] went forth to fully implement this feature for FPGA 80386s.  

Instead of taking a cycle to find and allocate the memory required for executing the next instruction, the 386 would start this in the previous cycle. This is achieved in hardware by nature of having a separate memory management unit. In the FPGA, the key difficulty proved to be in getting the computation fast enough to execute within a single cycle. This change netted an approximate 9% performance benefit. However, for [nand2mario] this was too small a performance uplift. 

Some rewrites of the store cue allowed for cutting a cycle out of the process further improving the performance. However, more performance required slight deviations from the design of the original 386. Because code-branches are performance critical, the z386 project now computes the branch memory jump several cycles earlier than the 386, reducing the cycle time for the jumps from 9.25 to a mere 6. Some final changes to the microcode decode frontend rounded out the optimizations covered in this latest blog post.

The net result is an approximate 39% increase in performance in the all important DOOM benchmark. The z386 still not a complete project, the performance is still lacking compared to the 386, and it remains unable to boot Windows. X86 is complicated, which will take time, so make sure to stay tuned for more coverage! While you wait, make sure to check out our original writeup of the z386 project. 

Pauli Rautakorpi, CC BY 3.0.

 

 

Breaking Enigma With An FPGA, Just Like At Bletchley Park

The pioneering work done by Alan Turing and others at Bletchley Park in England was perhaps as important in the history of technology as it was the history of the war. Given the last 80-odd years of technological development, their revolutionary work should be within the realms of a student project — which it was, specifically in ECE 5760 at Cornell University. The work was done by [Erica Jiang], [Kelvin Resch], and [Isabella Frank].

Nowadays if someone told you there was a code to be broken, you wouldn’t be reaching for electromechanical devices, but you just might think of trying an FPGA. After all, the programmable gate arrays allow for much faster execution of fixed logic than software running on a traditional CPU. That won’t help much with modern RSA schemes, and for Enigma, it’s massively overkill, but doing it that way was a great learning opportunity for the students.

Their project emulates the whole Bletchley Park cryptography apparatus, not just the Bombe Machine, and if you’re interested in learning about this piece of history you could absolutely do worse than to examine their documentation. If you’re into video, you can check out the final presentation and demo video below. Meanwhile if you’re wondering what the opposition was up to, we have good explainer of the enigma machine here.

Continue reading “Breaking Enigma With An FPGA, Just Like At Bletchley Park”

Z386: An Open-Source 80386 Built Around Original Microcode

There are many ways you can implement an Intel i386 CPU on an FPGA, with the use of original microcode probably being one of the most interesting approaches. This is what [nand2mario]’s z386 project does, with a recent blog post summarizing the development so far.

This effort is similar to the previously developed z8086 project, which as one may guess does something similar, except for the Intel 8086 CPU. By executing the original microcode you’re basically guaranteeing close compatibility with the original hardware, though of course the sheer scale of this microcode between an 8086 and 80386 is quite different.

There’s a much larger instruction set with a correspondingly much more complicated internal state to keep track of, including all those newfangled features like memory management, paging and register debugging, as well extensions to protected mode that began with the i286.

Currently z386 runs on a number of FPGAs, including the Altera Cyclone V and Gowin GW5A, with performance equivalent to a ~70 MHz i386 albeit with slightly worse cycle efficiency, some of which could be due to the limited 16 kB cache compared to the 32+ kB cache in the fastest i386 CPUs. Either way, it’s more than enough to run all kinds of software, including games like DOOM.

Important to note is that the goal here isn’t to be more performant than cores such as for example ao486, but more as an archaeological reconstruction of the original hardware and its interaction with said microcode.


Top image: line-up of Intel 286, 386 and 486 CPUs. (Credit: Sgroey, Wikimedia)

Build The CPU, Then Build The Calculator

It’s possible that among Hackaday readers are the largest community of people who have designed their own CPU in the world. We have featured many here, but it’s possible that not so many of them have gone on to power an everyday project. Step forward [Baltazar Studios] then, with a scientific calculator sporting a self-designed CPU on an FPGA.

The calculator itself is nice enough, with a smart 3D printed case, an OLED display which almost evokes a VFD, and very well made buttons. But it’s the CPU which is of most interest, because while it follows a conventional Harvard architecture with a 12-bit instruction set, it works with 4-bit nibbles. This choice follows one used by HP in their calculator designs, seemingly because it can be optimised for the binary coded decimal which the calculator uses.

With calculators being yet another app on our spartphones or comnputers, there seems to be less use of calculators outside of education in 2026. But if you are a calculator user there’s nothing like a calculator you made yourself, and with a CPU of your own design it has few equals. We like this project almost as much as we like the Flapulator!

It’s An Apple Lisa, On A FPGA

Most of us will know that Apple’s precursor to the Macintosh series of computers was a machine called the Lisa. Something of a behemoth compared to those early Macs, it had a price to match and wasn’t a commercial success. Working Lisas survive, but unlike a Mac you won’t find many at your local swapmeet. But what if you really must try this early Apple GUI? Never fear, because [AlexElectronics] is here with a much more accessible version on a FPGA.

This Lisa has a surprisingly large PCB compared to the size of the FPGA, because of the number of connectors. It takes the approach of mixing new and old in interfaces, for example as well as original Lisa keyboard and mouse support, you can also use modern USB versions. There’s also an HDMI output for a modern monitor, and an SD card. Unexpectedly alongside the FPGA there’s a 40-pin DIP, it’s a UART  chip because there’s no handy pre-built one for that particular chip. We’re told it will be up on GitHub when finalized.

Keeping old computers alive, especially rare ones, is hard. We like projects like this one, and we hope to see more developments. Meanwhile you can see the machine in the video below.

Continue reading “It’s An Apple Lisa, On A FPGA”

Taking Polyphony To A New Level

There are all manner of musical synthesis techniques, from the early electromechanical instruments through analogue tape systhesis, the all-electronic waveform synthesisers of the 1960s onwards, and Yamaha’s FM systhesis of the 1980s, to name but a few. One of the attributes of such a machine lies in how many voices it has, or in simple terms, how many notes it can play simultaneously. Electronic complexity limited those early synths, but what happens on an FPGA where vast numbers of circuits can be made with little extra cost? [Tsuneo.Ohnaka] is pushing the envelope a little, by cramming 10240 individually controllable oscillators onto a Terasic DE10-nano FPGA board.

While this thing can in theory generate 10240 different notes at once, in practice that doesn’t mean it has 10240 voices. Instead he calls it a spectrum engine, in that with such a large number of oscillators all with individually controllable frequency, phase, and amplitude, he’s made the part of all those Fourier transform maths where all the different frequencies are combined, in hardware. It’s as though you had a sound card which wasn’t based around a DAC fed with samples, instead all those spectrum points you’d derive from a Fourier transform. Because it’s a massive parallel array of real oscillators it all happens concurrently, instantaneously in real time, and is not held back by the processing constraints of a microprocessor. Think of it as something akin to a software defined radio transmitter, but for the world of audio synthesis.

In that light, it can emulate all those other forms of audio synthesis driven by software, but without the software overhead of generating the waveforms. It’s certainly a different approach to generating audio from a computer, and he’s posted a cacophonic demo video below of it as an 80-voice polyphonic synthesiser. We like it.

Continue reading “Taking Polyphony To A New Level”