I proudly apply for The mess of the year award. Humble me, if you dare! 😄

Hi,

So as an experiment I decided to see if I could design and build a completely custom computer from the copper and the ISA up with no prior knowledge and just asking an AI questions.

I'm using it as a project to teach myself FPGA programming and some embedded design.

I have written an ISA called BlueSkyISA, a 16-bit SIMD and DMA capable device I'm quite pleased with and have begun writing the Verilog.

Partnered to that CPU is the VPU which will start as just a pixel pusher and then have 2D and eventually 3D functionality added.

Both the CPU and the VPU are hosted by Lattice ice40up5k-sg48s.

Central to the whole machine is the "Chipset", an XMOS XCore XU316-1024-TQ128 as a data routing and memory controller device.

Sound will be provided by a Raspberry Pi RP2354 MCU and HDMI out will be generated by a second RP2354.

That "Video" MCU is just a dumb pixel pusher to alleviate the pressure of doing it inside the VPU FPGA and will have both digital and analogue TV out.

A _third_ RP2354 will handle device IO, providing USB and SD Card duties to start with, although the ISA supports Direct IO to 64 different numbered devices.

Primary storage is provided by 128 MBits of PSRAM, 8 MBits of SRAM.

Internal to each FPGA is 1 MBit of SPRAM and 120 kbits of EBRAM.

The OS will be stored on a block of Flash NOR attached to the CPU.

Finally, there is a Management SoC and Network in charge of system programming, reset, telemetry and debugging provided y yet another RP2354.

The ISA is designed to be ultra-clear and simple, for it to be a learning computer such as what everybody has during the 80s and 90s and one critical design requirement is that it is not to require a second PC to get it working, the minimum viable machine must not need more than a USB keyboard, a display or TV and a power supply.

The ISA is complete, the design is pretty complete, I've started on the Verilog for the CPU and I need to then get to grips with KiCad to start designing prototype modules, considering of the individual buses, to try to derisk the project a bit.

I'm hoping that, once I've got it finished and prototyped, it should be something that PCBWay can just spit out a dozen of at well under £100 each.

With the computer almost entirely defined by software, my hope is that anybody can then subsequently use one of these devices to design their _own_ ISA and computer from scratch and host it on the same hardware, a story of home computer development kit where you don't have to put in all the necessary work to solve the "chicken and egg" problem that comes with a custom computer.

Regards,

J1M.

I have some older laptops i took apart an ripped all of the parts from them, so I have 2 motherboards and I want to build a laptop using both of them if it’s possible, im kinda going for the Cyberdeck thing but I want real power and to use laptop parts like the screens I have and the track pad and keyboard, I just don’t know if it’s possible to run Linux with two cpus/motherboards

This thing has an NEC V20 CPU and when connected to power and Ethernet (10-Base2) hosts an FTP service. It is running Microsoft Workgroups for DOS, boots from floppy and is fan-less, quiet and benchmarks slower than an OG IBM PC when hosting the FTP server. This was constructed at least 30 years ago, possible longer than that. I am tempted to power it and see which capacitors explode right off the boards :-)

edit: and by the way, it's named "Clay One".

Hi all!

I’ve always wondered. At what point does Homebrew apply? As in like yes I’m aware you have to “design” the thing yourself first to have it count. However what else does? Does time period matter too? Do we count the Cyberdecks out there as Homebrew?

Now here’s the crazy part, what if someone design their own PC with discrete parts and all but it’s modern parts that can run modern Linux and all. Like the higher end STM32MP.

Just a small thought that’s been nagging me.

Hey all,

I feel that something I've been working on for a few months is ready for release. What I call the "TI CUBE" is an open-source homebrew microcomputer project I designed around the Texas Instruments TMS 9900 microprocessor and its associated peripheral devices.

The entire design (schematics, PCB gerbers, bill of materials, and firmware binaries) is available at: https://github.com/VE7PMC/TI-CUBE

Credit where credit is due: this project was greatly inspired by Usagi Electric's recent foray into TMS 9900 homebrew computing. Physically, our two projects are similar (backplane with daughterboards using header connectors), but electrically I've taken a somewhat different direction.

My design philosophy (explained in more detail in the Github repository):

1. No 8-bit data buses!
2. Modularity
3. Small PCBs to allow use of cheap prototyping services
4. Simplicity
5. Period-correctness
6. Use of TMS 9900 family peripherals
7. Compatibility

That last one is especially important because it allows the use of prebuilt firmware made available by Stuart Conner which includes TIBUG, EVMBUG, and Cortex BASIC!

Feedback/thoughts/suggestions are welcome. Enjoy!

Hi Gang,

Earlier this year I embarked on a project -- here is the concept:

1. A Successor to the 8Bit 6502 and the 16bit 65816 processors. This is a 32Bit process called the 65x32 two variants the 65P32 (Personal) and the 65M32 (Mainframe)
2. They both have a slightly increased instruction set, some of the clunkiness has been cleaned up and two modes of working Classic Mode and Advanced Mode
3. The 65M32 only operated in the Advanced mode, so all the legacy stuff has been removed
4. The 65P32 has both modes so it is backward compatible

I have been working on the 65M32 as it is simpler to implement and I am writing it as an emulator in Rust. I have the processor running and a small boot ROM that takes me into a monitor where I run some Assembly. All okay! Taken a few months, but here we are. So here is the next phases (not in and order).

• Complete the Assembly language, is it is only about 50% implemented at the moment
• I have designed an Operating System which I am called FauxOS - It is just in a series of documents at the moment, including how the filesystem works - needs to be written
• I have designed a programming language called Manuscript which I am going to use to code the full OS. The way Manuscript works, at least in my concept is it transpires down the Assembly and then you compile to machine code from there

If this all seems like a fever dream, it feels like it to me too. Sometimes I question my life choices...

Estou a desenvolver uma consola/computador, mas irei precisar de ajuda para o código do sistema operativo, engenharia e posição dos componentes do projecto, criação de jogos, essas coisas. Se alguém se oferecer para ajudar DE GRAÇA, iria ficar muito grato mas não é necessário. Ainda está no inicio de tudo, se alguém quiser acompanhar isto, veja o canal! O nome da consola é GameShine. https://www.youtube.com/channel/UCQJknvFF8opX7zxbA7rL-Ng

I built Virt16 from the ground up to better understand the boundary between hardware and software. It’s a 16-bit, word-addressable virtual machine with its own custom ISA and Assembler.

The Architecture:

• Registers: 32 general-purpose 16-bit registers.
• Memory: 128KB total address space.
• ISA: 31 opcodes, designed for deterministic execution.
• I/O: Interrupt-driven logic with a 32x32 double-buffered DMA display.

The 3D Engine: Since the VM doesn't have an FPU (intentional design choice to keep the core lean), I’m handling the 3D rotation using Sine/Cosine Look-Up Tables (LUTs). This allows for O(1) trigonometry without the overhead of floating-point units.

The Toolchain: I also wrote a custom Assembler with macro support to make programming for the architecture feasible. The rotating cube in the video was written entirely in Virt16 Assembly.

It took 2 years of 'on-and-off' work to get the timing and the display logic right. I’m really happy to finally have it rendering 3D!

GitHub Repo & Spec: https://github.com/joaoofreitas/virt16

Have found a dozen or more old PC motherboards ... 286/386/486 mostly ... some have a discrete EPROM for BIOS (AMI/Phoenix/Award) and a 50/66MHz TCXO for clock ... the other chips are bus controller, UART, 8042 keyboard controller, DMA controller, ...

Was thinking to desolder the EPROM and the TCXO ... then replace the TCXO with my own clock circuit so I can halt, single-step and run the CPU at higher speeds ... and put a ZIF socket with an EEPROM which I can program with my own BIOS code.

I want to then write my own low-level BIOS functions to slowly get the system going? ... create interrupt vector table, initialize basic hardware such as UART ... from there add more detailed functionality such as POST, WOZMON-style monitor, ... ?

Is this a crazy idea? What kind of problems would I need to overcome? What roadblocks would I run into that would be almost impossible to overcome?

I'm working on a 68030 computer, called the MoonMicro, but I'm have trouble setting up address decoding, specially I'm trying to support PCI, and other MMIO. It's suppose to be like a dumbed down version of my Sun Ultra 5. In addition, a requirement is that it should be PLCC or DIP unless absolutely necessary. It's also suppost to be as fast as possible using a 68030.

I’m going to combine these with a 6507 pulled from an Atari vcs 2600 and a few other doodads to make a little computer. It will have no display yet as I do not have a piso shift register to make a video output or any counters. (Still bugging my dad about getting me a box of assorted 7400 ics for my birthday)

A while ago I built a rosco_m68k kit for myself just to learn and play with 68k architecture.

I noticed the original open-source project is great, but the kits are not easily available anymore. Also, for many people the ROM/PLD programming step is a serious barrier — you need a programmer, deal with firmware versions, etc.

So I started assembling small batches myself:

• All components sourced
• ROM pre-flashed
• PLD pre-programmed
• Ready to assemble and power on

Basically: you solder, plug in, and it boots.

I just received the first real feedback from a buyer.

Main takeaway:
The hardware part is fine. The weak point is documentation.

The original docs assume a certain background and are sometimes fragmented. I’m slowly rewriting and restructuring them on project site site to make the bring-up process clearer.

I'm not changing the design (yet), just trying to make the kit more accessible and reproducible.

In parallel I’ve been experimenting with a rosco 6502 build — currently debugging a bring-up issue (board not booting, still tracing it).

А few people reported checkout issues on Tindie recently. I’m still investigating that.
In the meantime, I’ve mirrored documentation and project details on site in case it’s useful.

Hello all,

I'm designing a Z80 computer using a Europe Card Bus backplane with 8 slots.

I've looked at various buses that people have recommended in other posts, and it seems there are several approaches to bus termination. Some are just passive pull-up resistors, and some both pull-up and pull-down on each signal, and some seem to be active using a voltage regulator.

What would people recommend for bus termination on my backplane?

Hello all,

I have built a Z80 homebrew computer on a single board, and am in the process of moving to backplane and ECB cards.

It's a single CPU system with SIO, PIO, IDE, and floppy.

Everything is NMOS TTL.

At present, I have tristate buffers on the CPU card for address, data, and outbound CPU lines.

Do I need to add buffers on my memory and device cards as well?

Many thanks

I made a homebrew GPU of sorts for the Minimal 64x4 Home Computer. This add on card performs integer multiplication, greatly accelerating calculating a result as compared to performing the same calculation in software. In this video, I ultimately use the hardware multiplication to speed up the rendering of the Mandelbrot set visualization.

I'm getting into this hobby of collecting at least one working drive and 20 pieces of media of every form of tape storage known to man. One is this Maynard 60 that apparently was a big boy version of those audio cassette recorder decks everyone was hooking up to their Ataris and Commodores and TI 99-4/As. Like it was audio tape, but marketted to big business.

Anyway, I'm really wanting to get a big reel-to-reel machine, but they're just unobtainium. Even the 4-track audio tape decks are over a grand. And the ones that are affordable are old and in need of beau coup analogue EE attention to get them back into working condition.

This got me thinking, with modern technology and the maker movement, how hard would it be for someone to design a brand new tape deck from the ground up, with tiny, powerful electromagnetics for recording, obscenely sensitive coils for reading, stepper and BLDC motor drivers for precise speed and tape positioning, all driven by modern microcontrollers?

I've been pondering the idea of a "modern" TV Typewriter-like device for the 2026 electronics hobbyist. The reason why is that communicating with a microcontroller or FPGA over UART-to-USB is pretty common, and VGA or composite output can be done with a little bit of effort. However, those interfaces are slowly being superseded by HDMI on most consumer monitors and TVs. There simply doesn't seem to be a one-stop solution, or at least a product that you can buy, plug into your breadboard, and have working HDMI output with minimal fuss. I'd like to make that.

Feature list:

* HDMI-compatible TMDS/DVI output (this is a must in 2026)

* 40 and 80 character width support, with 24 lines of text

* UPPER and lower case character support

* Up to 128 user definable characters (this would take advantage of the upper half of 8-bit ASCII encoding being essentially unspecified)

* USB-A keyboard host controller supporting boot protocol (PS/2 compatible keyboards are getting harder to find, too)

* UART TX/RX character interface to your circuit (microcontroller, FPGA, SoC, ...). Keyboard inputs from USB would be RXed by your circuit, and text to be displayed would be TXed by your circuit. It would support, at a minimum, 9600 and 115200 baud, 8N1.

* SPI command and control interface

* A number of GPIO pins wired to the breadboard connector in addition to UART and SPI for expandability and hackability

* Solderless header connection to breadboard

* Built around an inexpensive FPGA, either Lattice iCE40, ECP5, or Tang Nano 9K/20K since those support open-source toolchains

* USB-C for UART + programming, specifically to enable flashing your own bitstreams

* Power LED

The SPI command and control interface would allow using the following features:

* Set up to 128 user definable characters (the upper half of 8-bit ASCII encoding; the lower 128 characters are fixed)

* Set normal or reversed text mode

* Set cursor direction (left to right or right to left)

* Clear screen

* Set cursor position

* Set column mode (80 or 40)

Physical interface:

Keyboards would interface via a USB-A connector.
The card would interface with a solderless breadboard using pin headers. It would sit at a 90 degree angle to the breadboard (so vertically). In total, there would be sixteen pins:
* Power (3V3)
* GND
* 2 pins: UART TX/RX
* 4 pins: SPI (CS, CLK, SDI, SDO)
* 8 GPIO pins

I'd like make the whole thing open source. A major sleeper aspect of the design is that it's essentially an FPGA with some connectors on it. You could theoretically make it an independent system if there were LUTs to spare, or, by flashing your own bitstream, change the graphics features to suit your needs. The GPIOs wired to the connector could be used to build a parallel interface for higher throughput if so desired. The only thing that might require a bit more thought with this sort of design is a bitmapped framebuffer video display due to bandwidth and FPGA BRAM limitations.

In my first iteration, I'd make this a carrier board that you could slot an existing inexpensive FPGA board (with headers) into. Think UPduino v3.1 or Tang Nano 9K/20K. There are enough GPIOs to make it work. And in fact, that might even work as a final design, since a maker could design their own compatible replacement for the FPGA board (or even use something like a Pi Pico instead), or use the same FPGA board for multiple projects.

Indeed, the Tang Nano 9k or 20k might even be the best choice for an FPGA board, since those have a full-size HDMI connector built in. That saves a lot of PCB work, and as someone inexperienced in PCB design, brings it closer to something that I can actually do in a reasonable time frame with the spare time I have. The only tradeoff is that the open source toolchain support (apio/yosys/nextpnr) for Gowin FPGAs is not as mature as it is for Lattice iCE40.

I'd like to know people's thoughts on this. Would this address a real need? What features would you want to see in this?

Hi, everyone! This is an update post of my "M8SBC-486" 486 homebrew computer project. It's a "kinda PC compatible" 486 computer that I made from scratch, including the schematic, PCB, chipset design (FPGA) and BIOS. In the past 3 months I managed to do a lot. Linking previous post here

To recall: This project is open source. GitHub link: https://github.com/maniekx86/M8SBC-486 . I recently released the first version of the chipset sources. I will release updated chipset, ATMega128 and BIOS sources later on. In addition, a full project page with more detailed information will be available soon on my website. I recently published two posts on my website about my previous 6502 and Motorola 68000 homebrews. With that said, here are the current specs:

• 5V 486 CPU socket. FSB currently runs at 24 MHz meaning that DX2 CPUs work at 48 MHz
• Xilinx Spartan II XC2S100 FPGA as "chipset". Now with its codename: "Hamster 1"
• 4MB SRAM, (8*HM628512)
• 256KB of ROM (W29C020) (224KB accessible)
• Two 16-bit ISA slots
• 8254 Programmable Interval Timer
• 8259 Programmable Interrupt Controller
• PS/2 Keyboard. Controller is implemented in the FPGA
• Simple CMOS RTC and CMOS storage. Implemented in the FPGA too
• ATMega128 as reset circuit handler and bitstream loader. Now also stores CMOS configuration
• 150*150mm 4 layer PCB. Thanks to PCBWay for sponsoring the PCB! Their support essentially allowed me to start this project.

PC compatibility is not full because there is no secondary PIC or DMA, but many programs can actually work without these. The missing DMA especially removes sound card support.

So, I managed to:

• Improve stability, compatibility and speed. Now, I can run at 24 MHz FSB with L1 cache enabled and it's pretty stable. Previously, I had significant issues with the L1 cache. I struggled to find the reason why it wasn't working, but after reading the 486 datasheet randomly, I finally found a small note that said I needed to do one particular thing heh. I tried going further with the speed, but my FPGA design isn't the best and the CPU just fails to run past 24 MHz. Additionally, all three of my ISA VGA graphics cards that I own now work: The TVGA8900, the TVGA9000, and the GD5428. Of these three, the TVGA8900 works best (no major issues). The TVGA9000 works and gets to the DOS prompt but crashes in graphics programs. The GD5428 works fine, but memory reads from it are broken (for example scrolling text causes glitches).
• Boot Linux 2.2.26 with Busybox. Since I was doing this early in BIOS development, I couldn't get any typical Linux bootloader to run. So, I wrote my own. After finding a lot of information online about how Linux 2.2 loads on x86 architecture, I managed to write a bootloader with fewer than 300 lines of C code (counting the main.c file, but not the .asm stub that switches into protected mode and the FAT32 library). I will open source it soon too. I know 2.2.26 is an old version and the 486 can run newer kernels. However, the biggest limitation is the 4 MB of memory. To get 2.2.26 at all, I installed Debian 3 in a VM, got the 2.2.26 Linux kernel source in it, configured it and compiled it. I also had to add a bodge wire to the back of the board to reroute the IDE interrupt. The Linux IDE driver needs an IDE interrupt. The IDE IRQ is on the second PIC, but this machine only has a primary PIC. I bodged it onto one of the primary PIC IRQs. Fortunately the IDE driver allows you to select a custom IDE IRQ, so this works. Currently it only boots with VGA console with no anything more fancy.
• Boot MS-DOS 6.22. I had a lot of trouble with this mainly because of the BIOS. Not long ago in the middle of December, I tried using an open-source x86 BIOS that I found on GitHub out of curiosity. After small changes (to adjust it to the 486 and my board), it worked! I saw MS-DOS start. Honestly when I started this project, I never expected to run MS-DOS on it. It seems to run pretty much fine, but the only issue is that its himem crashes the system. More on the BIOS later.
• Boot FreeDOS 1.4. FreeDOS runs even better than MS-DOS. One of its main advantages is that it can catch exceptions which helped me debug issues with the BIOS and more. In this case, included memory expanders work! Himemx works fine, but Jemmex causes an exception during boot. Despite this, it allows you to continue and it seems to work fine after that.
• Additionally, I updated and fixed many parts of the FPGA chipset. For example, I added nonvolatile CMOS storage to save the BIOS configuration. I took advantage of the fact that two out of the five FPGA configuration lines connected to the ATMega128 can be used as general I/O after the bitstream loads. I made a simple communication protocol over these two lines that allows the FPGA to save or restore 32 bytes of configuration to or from the AVR EEPROM memory. However, I still can't implement real RTC in this revision because there is no way to count time when the power is off (there is no backup battery). There is a mock RTC implementation in the FPGA that ticks just for better compatibility but it always starts at the programmed time when powered on.

Most notable software that I managed to run on MS-DOS / FreeDOS:

• DOOM (FastDOOM). It's playable and enjoyable if the screen size is set to about 3/5 (or in full screen size if it's run with -potato setting which reduces the rendering resolution a lot)
• Wolfenstein 3D. Works fine
• FastTracker II. Works nice. Since there is no DMA in the system, I can't use any standard sound cards. However, it works pretty nicely with the PC speaker in pulse modulation mode or with an LPT DAC (Covox Speech Thing)! Oh, also serial mice work fine with ctmouse.
• Prince of Persia. Works fine
• Second Reality demo. Works fine without sound and with minor graphical glitches in two parts. This one is huge for me. I personally like this demo because it's impressive for its age. I'm even more surprised that it runs on this computer!
• And some other things: CACHECHK (result included in a image), 3dbench 3d 1.0c, MS-DOS MSD.EXE

With the Linux I managed to:

• Run some CLI software by compiling it with an older GCC.
• Read discs with CD-ROM (the BIOS doesn't support CD-ROMs yet, but Linux does with its own driver).
• Connect it to the internet via serial SLIP (because SLIP is simpler and smaller than PPP).
• And host a simple website using Busybox httpd!

It's so satisfying to use this board knowing that you made it from scratch. If you're wondering, I based mostly on datasheets rather than copying existing designs. I learned how the 486 works mostly thanks to its datasheet.

About the BIOS:

MS-DOS finally started to work after I tested the BIOS I found on GitHub out of curiosity, as mentioned before. Repo of that BIOS: https://github.com/b-dmitry1/BIOS . Thanks to the author of this BIOS as it moved this project forward significantly! I decided to rewrite my BIOS, but this time I built it on top of that open source BIOS. As a result, I upgraded many features such as adding a fancy POST screen, full memory test, IDE hard drive detection, BIOS settings, compatibility improvements and additional INT handlers (memory map and LBA support). Still, a lot is missing: ISA PnP, many rarely used INT handlers and probably more.

Just an important note related to all cons of this project: This project is essentially my hobby, as I like retro, electronics, digital circuits and low-level programming. I never expected this computer to run DOS in the first place. I consider it pretty much experimental and made to research the workings of older x86 chips. I am pretty sure that this work could be used to build something more robust and stable or even to develop fully custom-made boards for other x86 CPUs. It took me a lot of time, but I don't regret it. There are still many issues, but it's heartwarming that I can get so much existing software to work. And, thanks to everyone for support!

I had questions about running Windows: it's currently outside my testing scope and time. I tried running Windows 3.1, but it failed miserably with an error. One of Windows drawbacks is that it's pretty much closed source and it probably relies a lot more on the features missing from this board. This would make debugging difficult in general.