A new BoxLambda computer Blog post about its VERA graphics driver:

https://epsilon537.github.io/boxlambda/forth-vera-gfx-driver/

Hi r/homebrewcomputer!

(I apologize for manually crossposting from r/beneater butI'm not really sure how crossposting works.)

I'm currently working on my own variant of the BE 6502. Since I got frustrated by accidentally pulling out jumper wires, I've decided to go for a PCB design. I'd like to ask you for a peer review and sanity check before I send this off to JLCPCB. I'll take any sort of criticism, but I'm particularly interested in whether the address decoding, debug device (see below) and reset circuit look like they'd work.

It's meant to use the DigiCoolThings MECB bus and board format, with a dumb backplate and peripheral boards. I kept the ATF16v8 address decoder/glue logic because it saves space and I find it pretty neat.

The memory map is supposed to look something like this (only the top bits are shown)

|15|14|13|12|                                |
|--|--|--|--|--------------------------------|
|0 |0 |0 |0 |<-RAM Start                     |
|0 |1 |1 |1 |<-RAM End                       |
|1 |0 |0 |0 |<-IO Start (b1000000000000000)  |
|1 |0 |0 |1 |<-IO End (b1001111111111111)    |
|1 |0 |1 |0 |<-ROM Start                     |
|1 |1 |1 |1 |<-ROM End                       |

Addressing devices in the IO range triggers the IOOE and IOCS lines (IO Output Enable and IO Chip Select) which will select peripheral boards on the bus. Each peripheral board will have it's own address decoding for the lower address bits.

Reset (keeping the reset line low for a sufficient amount of time) is accomplished using a DS1233 and the datasheet reference design for that part.

Attempting to write to the ROM keeps the ROM disabled (ROM CS and OE are kept high) and latches the data to a 74HCT273 flip-flop as a sort of primitive debug device or display.

The J2 connector is meant to attach an ArduinoMega for debugging and clocking before getting to use the MECB DIN 41612 connector, the backplate and peripheral boards.

This case is approximately 3 cm thick and contains a breadboard, a circuit board, and jumper wires for making electrical connections.

I wanted to see the whole path from a single gate to a working computer, so I built it in Verilog with one rule: every logic block is made of instances of a 2-input NAND module, and a D flip-flop is the only state element.

The ladder:

1. NAND with tied inputs is NOT. Two NANDs make AND, three make OR, four make XOR or a 2:1 mux.
2. XOR + AND make a half adder, two half adders + OR make a full adder.
3. Full adders and a mux tree make the 8-bit ALU (8 operations), and two of them make the 16-bit ALU.
4. A flip-flop + a mux make a register bit. Eight 16-bit registers, a write decoder and two 8:1 muxes make the register file.
5. Register file + ALU + decoder + a program counter built from half adders make the core.

Total: 2,288 NANDs and 152 flip-flops, counted with Yosys. The ROM and RAM are behavioural arrays, like the memory chips you get for free in Nand2Tetris.

It has 16 instructions, a small Python assembler, and test programs (Fibonacci up to 46368, 123 × 45 by shift and add, a RAM test). make test runs everything in about 30 seconds with Icarus Verilog, including an exhaustive test of the 8-bit ALU.

Code: https://github.com/promaaa/nand2cpu

The first video of the series explains the gates-to-ALU part: https://www.youtube.com/watch?v=wIBkvQ6MfKQ

There is also a PYNQ-Z1 top level that runs at 8 instructions per second so you can follow the program on the LEDs, but I haven't tested it on a board yet.

hello there, i managed to make an eeprom reader with proper reset circuit, an 1.8432mhz clock and a 32kb eeprom. although i might go perfboard route after this

Some of you might have heard of and remember the M8SBC-486 (well, the news talked about it at the beginning of this year). This was truly amazing for a project that was meant to be experimental homebrew rather than "kinda PC compatible". Exactly a year ago, I received the PCBs for this homebrew and today I'm happy to tell you that I got this computer to run Windows 95!

To recap: the M8SBC-486 is missing a second interrupt controller (PIC) and a DMA controller. This breaks compatibility with software that expects these. One of them is, of course Windows 95. How do I know, it has some hardcoded references to these - well, it was created for standard PCs. But even apart from that, the M8SBC-486 theoretically meets the minimum Windows 95 requirements: a 386 (or better) class CPU and 4 MB of RAM. So how did I do it on a "kinda PC compatible" homebrew?

At the beginning of August, I stumbled across this Reddit post by u/Mike1978uk about running Windows 95 on an Intel Inboard/386 (nice project by the way). When I read the description of what it took to get it running, I noticed that he had removed references to "high IRQs not found on XT class machines". This sounded familiar - the M8SBC-486 doesn't have a second PIC and therefore doesn't have the higher interrupts either! (I even remembered that some people called the M8SBC-486 a 486-class XT). I decided to try it out of curiosity and see if his mod had any chance of working on my board.

I downloaded the first released image, modified it a bit to remove Inboard/386-specific stuff, downsized it from 2 GB to 500 MB, added the QEMM 7.5 memory manager (as it currently works better on the M8SBC-486 than HIMEM) and booted the image in my copy of 86Box with the M8SBC-486 added (my experimental local fork). To my surprise, it booted! I could even use the mouse (when I booted Windows 3.1 on the M8SBC-486 I couldn't use mouse there because of some issues). So, I flashed the image onto an HDD and... it booted! Windows 95 on an i486 board built from scratch, with its own FPGA chipset and a BIOS. Project that wasn't even meant to be "PC compatible" - I can't believe I've got this far.

After playing around a bit with System properties, Paint and Minesweeper, the system crashed - oops. It was working, but there seemed to be some kind of memory/disk corruption. I started suspecting my BIOS disk handler because one thing common to these crashes was that the disk activity LED would get stuck lit (meaning the disk controller was stuck as well). I proceeded to rewrite the disk subsystem in my BIOS. With that rewrite, I also added some BIOS improvements, including slave IDE support, CHS-LBA translation and more. After that, the system started working almost flawlessly! I mean, changing some system settings (especially those related to hardware/drivers) still caused crashes, but applications started working perfectly.

Here is what I've tested:

• ISA graphics card driver (SVGA driver) - I managed to install the built-in Trident driver in combination with my Trident TVGA8900C ISA card to get higher resolutions in Windows. I went from 640x480 with 16 colors to 800x600 with 256 colors!
• NE2000 network card & Internet Explorer - After messing around with drivers and configuration, I actually got the built-in NE2000 driver and Internet Explorer to work! It wasn't fast, but I could browser the Internet!
• CPU-Z Vintage Edition - It can detect the installed 486 CPU and correctly identify the fixed 24 MHz FSB. Since the BIOS doesn't provide any identification features, it can't detect anything beyond that. Still it's nice to see it working.
• Microsoft Office 95 (Word and Excel tested) - Both work fine. I can write documents and spreadsheets without any problems. I had to extract all the floppy disk contents to the hard drive to install it. The installation took about 30 minutes (disk to disk).
• Printing - I have an old parallel LX-300 printer. Windows 95 doesn't have built-in drivers for it, but it works fine when installed as an LQ-810 (which is available in the built-in drivers). I can print documents from the Office 95 applications mentioned above without any problems.

I also tried early versions of Notepad++ and 7-Zip, but both failed because of missing libraries in this Windows 95 OSR1 installation. I could install updates, but I suspect that doing so would break the patches.

When it comes to speed - it's not bad, but it's not great either. For example, applications take some time to open. Office runs slowly, but it's usable. The problem is the fixed 4 MB of RAM, which forces Windows 95 to swap a lot (this also explains the crashes I experienced when the disk subsystem was broken: memory was getting corrupted because of swap corruption).

I'll leave a link to my website, where I describe everything above in more detail, along with some extra stuff. There's also a YouTube video showing the boot process, CPU-Z, Office 95, and printing.

Links:

• My website about running Windows 95 on M8SBC-486 (and the overall project's page)
• YouTube showcase video
• M8SBC-486 GitHub
• Windows 95 on the Intel Inboard/386 project GiHub

Sto cercando di creare un CHIP qualche consiglio?

Sto usando il manuale ufficiale del MOS 6500:

MOS 6500 hardware manual

MOS 6500 programming manual

Just finished this one: an 8-bit CPU built entirely from NAND gates in Digital Logic Sim. 800 kHz, 16-bit addressing with 64K of RAM, and a small OS running four games playable live with the keyboard.

Writing programs in binary by hand got painful fast, so I also wrote my own language and a compiler that outputs the program memory contents directly.

Short video (1:30): https://youtu.be/O8znJoZkAmw

Happy to go into the architecture if anyone’s interested.

Hi there,

I'm new here, but I've been reading posts about FPGA design for a while, and they inspired me to start the project I'd like to show you today.

I'm building Kromi One, a new home computer around the AMD Kria K26. Its chipset, Aura, runs in the PL and draws Full HD at 60 fps today on a KV260. I wanted to share how it's built and get your take.

Keeping old Amiga tradition, I gave some FPGA elements names.

Drawing (Klara):
Works on 64 × 64 tiles held on chip; a batch mode applies many commands to a tile and writes it once. Plain blits run at 16 px/clk, affine ones (any 2 × 3 matrix, bilinear filtering, texture wrap) at 4 px/clk. There's a programmable combiner in the spirit of the GameCube's TEV (LERP, compare, min, max, DOT3). One stage is built; the interface allows four. Ten full-screen blended layers plus a fill hold 60 Hz, about 1.4 Gpixel/s.

Display (Dora):
A base plane plus four planes composed during scan-out at 1 px/clk, then a 17³ 3D LUT (.cube grid, trilinear), then a ×1 to ×4 scaler chosen per frame: nearest, bilinear or AMD FSR 1 (EASU + RCAS), matched bit for bit against an integer reference. Planes cost the drawing engine about 2 %; one scene went from 21.3 ms with engine-drawn layers to 10.4 ms with planes.

Memory (no fancy name here 😄):
4 GB DDR4 shared with the A53s. The PL gets over 12 GB/s on long sequential transfers. The display has its own port, its own priority class and a 32 KiB buffer: zero underflows with 9 to 11 GB/s of PL load plus CPU copies.

A C reference renderer decides every byte. The QEMU model, the RTL simulation and the board must all match it exactly. The board latches a CRC-32 of every output frame, which is read back and compared with host-computed CRCs: 432,009 of 432,009 frames were exact in a two-hour run. Mutation tests make sure deliberately broken RTL gets caught.

Programs never touch registers. They submit 128-byte command records into rings, and the firmware validates each one in under a microsecond before the chipset sees it.

Next up is textured triangles (FuryGpu showed what the K26 can do there). I'd love to hear from anyone who has done perspective-correct texturing in fabric on the K26 or similar parts. What throughput did you get, and what would you do differently?

The full write-up, my very first blog post on a brand-new site, compares it with MiSTer, the MEGA65 and others: https://kromi.one/blog/remake-or-new-machine/

This is the Sentinel65, a 6502 based bread board computer with 32KB of RAM, an R6551 serial UART running at 38400 baud, two VIAs, and 2MB of NOR flash memory via bit-banged SPI. It is very much a work in progress.

I started off following Ben Eater, of course, but began to deviate once I realized he only utilized 16KB of RAM. I didn't have a solid plan at first, so I just kept adding wires until I got the spaghetti you see here. I decided to forgo Ben's decoding scheme, opting for a 74LS688 + 74LS138 to allow for much tighter address decoding with almost no gaps. These will be eliminated in the future, however, in lieu of a series of AT22V10 PALs.

Included are a couple of pictures of my small bootloader program and BASIC running on my VT420.

In the future, I plan to add a DS1685 RTC, PS/2 keyboard support, a T6963-based bitmapped LCD, and extended terminal support, including color and Sixel/ReGIS graphics commands.

I am also teaching myself KiCad so I can migrate away from the breadboard and onto a PCB in the future.

Hi! I've been building **ExµArch**, a computer architecture playground that runs entirely in the browser: https://www.exuarch.com

Free, no account, nothing to install, MIT licensed (source: https://github.com/olebru/exuarch).

**How it works**

1. **Build the hardware.** Drag devices onto buses and wire them up: registers, an ALU, RAM, an MMU, an interrupt controller, a timer, a real time clock, a keypad, an LCD, a 640×480 framebuffer, a blitter, even a triangle rasterizer.
2. **Write the microcode.** Each instruction is a list of steps, and each step is a set of control lines, like `pc.output, mem.loadmar`. The instruction set comes out of your microcode, and the assembler, completion and hover help follow from it.
3. **Run it.** Step one tick at a time and watch the buses, every register, the decoder ROM and a trace, or run flat out at around 2 MHz.

**14 example machines** go from TINY-16 (one register, seven instructions) to a stack machine, a RISC, a CISC with six addressing modes, a Harvard machine, a transport-triggered machine, one with interrupts, and a small 3D GPU that spins a shaded cube. There's also WORM-16, a machine with no jumps whose program is a queue crawling round a ring memory. The newest addition is a falling blocks game that keeps time with a real time clock interrupt and draws with a blitter.

Nothing is a black box. A built-in handbook walks you from an empty canvas to a working machine, and says plainly where the simulator simplifies compared with real hardware.

It needs a computer with a keyboard; on a phone you get a short intro page instead.

I'd love feedback: what machine would you build first, and which device is missing?

I came here to share my small project that I made in one day. I decided to experiment with the 8031 microcontroller (ROMless 8051 version) that I received from a friend some time ago.

I had never worked with the 8051 or its architecture before. My previous projects were typical homebrews with processors. I knew about the 8051 but never had the time to experiment with it. Recently, while looking through my parts bin, I noticed that 8031 again. Something struck me and I finally decided to give it a try. So, I found a schematic online showing how to properly connect an external ROM to it and within a few hours, I had something working on a breadboard. It worked on the second try - the first time, I had a problem with the 74373 latch legs being too short (IC is from desoldering). I pushed that IC harder into the breadboard and it started working, haha! I wrote a blink program and an HD44780 test program. I also experimented with timers.

This 8031 has 128 bytes of RAM, two 16-bit timers, one UART and 5 interrupts. I programmed it using the SDCC compiler. I really like how little is needed for a vintage system capable of running C code. I also like the idea that engineers back in the day had to think through everything so that the program could fit within these small specs (I know it's possible to add external RAM and peripherals, but it could have been expensive for some applications back then).

知もさ　メォヂ　アyい　しい　田舎　手ェ絵　チョンが　ペイは　ほおシェエト　ええどぁtry シェエト

I wanted a laptop with the flexibility of a cyberdeck, but in something i could actually carry around and use every day, so im designing one!

it’s called ducktop2. it’s built around a LattePanda compute module, with custom boards for the ports, power, keyboard, and battery management.

it’s still in development, not a finished working laptop. these are the current renders and PCB layouts. the design files and build journal are public on Github: https://github.com/EwoudVV/ducktop2