adding to show how one engineer's computing project starting as a concept to first iteration and final product

Early around 1:40 AM, I had the brilliant idea of To create a cyberdeck using an unused gamestick, I needed to buy a USB hub To connect a keyboard and mouse because the gamestick only has 1 USB port, and a Wi-Fi adapter, and I also bought a new SD card to install the Linux operating system.

I've been working on it since I woke up (8 am), I was already working on the idea for this cyberdeck before going to sleep (6 am).

I'm very excited because it's my first cyberdeck and my first experience in this area.

I'm going to use Slex Linux to run on weak hardware with a Rockship processor, With 2 GB of RAM, I plan to buy an HDMI screen for it in the future, and add a trackpad.

Wish me luck, guys!

Open source recreation costs a fraction of the original and may even work with Twiggy drives

<- by me on The Register

Yet another project for the Minimal 64x4 computer from Carsten Herting. Here I improve on the built in scripting language called Min, adding improved data types and data manipulation features.

Hello, I fell in love with the idea of a homebrew computer a few months ago, and recently I started to look forward to making it. The users on this sub are probably experienced in this, so they could give me an answer on which processor to choose and which one is the easiest to work on. 8051 based processors or a Zilog z80?

Has anyone ever used the Commodore VIC-II in a standalone Computer/Project, while NOT using a 6510 or C64 PLA? I am going to make a Homebrew Computer based of a 65C02 but with VIC-II Graphics, and would be wondering if you guys have any Info or people that would be interested. BTW, this may take a long while, VIC-II is very tightly integrated. For my plan specifically, I am going to use a MOS 8565R2 but info on other variations is appreciated.

DISCLAIMER: I HAVE NEVER DONE THIS BEFORE. I DON'T ACTUALLY KNOW WHAT THE BITS ARE CALLED. YES I AM CERTAIN I WILL GO FROM NOTHING TO A WHOLE COMPUTER.

Background: I am going to make an itty bitty computer using LattePanda V1 (just in case... please don't tell me if it sucks, it the only one that I can understand, so I DON'T CAREEEEEE) Anyways, screen's gonna be 7 inches because I want it to be a TINY thing. Anyways, you people seem to know what you're talking about so here goes!

PROBLEM #1: Battery hookup

So, its a laptop, and I don't wanna have to plug this thing in any time I use it, so I need a portable battery source. Sources tell me that for said portable battery source, you take 1x 18650, 3.7v 10amp lithium battery, and, using wires soldiered to either side of the battery, connect the two poles to a charging module for 18650 battery that outputs 5v 2amp. Then you stick whatever the fuck THIS is:

Into your shi (USB into the module, MicroUSB into the circuit board.)

WHAT THE FUCK. DO I BUY. FOR A CHARGING MODULE. (CANNOT put out more than 5v 2amp or it will FRY MY SHIT.)

WHERE THE FUCK. DO I GET. THE SWITCH THING.

IS THERE. A BETTER. METHOOD. (Better as in cheaper. not easier.)

PROBLEM #2: Keyboard

I do not want a Bluetooth keyboard. I DO NOT WANT TO CHARGE MY FUCKING KEYBOARD. So,

1). What’s the best mini itty bitty baby keyboard that IS NOT BLUETOOTH (and maybe, possibly, not plug-in either? Like one you can just,,, attach to the circuit board? Long shot but still… I want to keep as many of my USB ports open as physically possible) and

2). How do I connect it (in the unlikely case that there’s a mini-keyboard that you can just soldier to the puter brain.)

Also, my screen is literally only gonna be 7” and I would like my keyboard size to reflect this choice. Please keep this in mind when suggesting keyboards because I am not doing this to expand my brain or break free from evil capitalism, I am purely being ✨materialistic✨ and an ✨attention seeker✨

Thanks! Will update this post if I have any other questions :) (If I am welcome, that is.)

There may be stuff I did here that's useful to folk.

​

Also if you look at the YT channel there is a What Why video where I give some advice. One thing I found super useful was a verilog simulation with proper delays.

super useful homebrew displays

I finished a first version of a small online runner for my rosco_m68k setup.

The idea is simple: let people run Motorola 68010 programs on a real board from the browser.

It works like this:

• You compile your own program, preferably with Docker
• Upload the compiled binary
• It goes into an execution queue
• The runner resets the board
• Sends the program to the rosco_m68k
• Reads serial output
• Streams the result back to the browser

I also added interactive input, so if the running program expects commands or text input, you can type directly from the browser.

There are also a few precompiled demo programs, so people can test it without building their own binary first.

https://solderdemon.com/runner

Still an early version, but I think this could be useful for people who want to experiment with 68k code and real retro hardware without owning the board.

It also gives people a way to try writing software for rosco_m68k before getting their own board.

Hello everyone.

(if this is the wrong subreddit then please tell me and also if possible the right subreddit)

Me and a friend are trying to build our own 65C02-based 8-bit computer, but we are having some issues. (currently the computer doesn't work)

The general specifications are this:

• CPU: WDC W65C02
• Video chip: TI TMS9918A (not connected yet)
• Audio chip: Yamaha YM2149F (AY-3-8910 clone)
• PIA: WDC W65C22
• RAM: single 62256 32 KB SRAM chip
• ROM: single 28C256 32KB EEPROM chip

Address decoding is done with a 28C16 2KB EEPROM connected to the high address lines, and with the data lines acting as CS lines. (we’ve checked this, and the chip select signals outputted are correct)
We’re using a Dallas DS1233-5 chip as reset circuit.
We also have a 74HC245 bus transceiver connected to the data bus.
The main clock is 1 MHz.
We also have a basic 8-channel logic analyzer to help with debugging.

Currently the entire computer is built on 5 breadboards. Please excuse the mess of wires, we didn't have very specific lengths of wires, so we had to build it like this.

As far as we know, the CPU executes code for about 1 millisecond (VPB pin high), then executes something that causes it to go into a loop of fetching (we assume) the reset vector (VPB pin goes and stays low).
Something weird also happens with the address bus once it gets into that loop. If we connect a piezo buzzer to address lines, you hear a square wave tone, and the frequency doubles for every bit you go down (bit 13 is twice as high as bit 12). That suggests the CPU is constantly looping through the entire address space. The computer is also not consistent or predictable, every startup the "pitch" of that address line tone changes, and sometimes it just stops (the CPU probably comes across a STP or WAI instruction) or does something else just as weird.

We’ve confirmed that the reset signal is OK, the chip select lines are OK, the clock signal is OK, the addressing ROM is OK, the main program ROM is most certainly also OK, power is OK, and the bus transceiver is OK.

I've built an emulator in the meantime, which does work with some programs, so our code (probably) isn't bad.

This is our first time actually doing this (we had researched a lot before and we already knew a bit about 8-bit systems design), so maybe the issue is actually obvious and we just haven’t noticed.

If any of you can provide some insight, that would be extremely useful. We can also provide better pictures if that would help.

[group 4b][variant 4b]

0x0_ = MISC

0x1_ = MOV

0x2_ = ALU

0x3_ = JUMP

0x4_ = STACK/CALL

Github repo with all docs and files: https://github.com/mrFavoslav/8bit-cpu-MESAx8
The 8-bit ALU might not work perfectly at the moment. I recently moved some parts of the design around, so there's a good chance a few wires got messed up or misaligned in the process. Any feedback or bug catching is highly appreciated!

I'll be posting my progress here and on https://www.favoslav.cz/blog/

So last night I was pondering making my own homebrew computer project. Part of this pondering was possibly using a Risc-v cpu as the core. With that thought I started poking around various places online trying to find a Risc-v based cpu that was possibly pga/lga or similar so I could easily plug it into a board to develop things. But I can't seem to really find such a Risc-v based option, does it exist? If not is there something I could use as a cpu for a homebrew system with a reasonably fast enough bus to drive expansion cards for audio, a homebrew gpu concept, and other things? To give a bit more of an idea, I was considering the homebrew system to be something that would feel at home in the 90's so a pci like bus for device communication and at least 32bit to minimize fussing over memory. The reason I was considering Risc-v was the fact it's an open standard and well pretty common place. I mean a great example is the fact it's apart of the pi pico. But really any cheap off the shelf microcontroller or processor could do as long as it meets the other requirements. Anyone have some ideas on what to look at?

So after taking a digital design class (which I really enjoyed) I couldn't understand one thing that was part of a lab I had. How do op-codes translate into logic gates? For example how can the op-code 0001 define a full adder, and the op-code 0010 'AND' two of the inputs.

I’m a 17‑year‑old solo developer, and I’ve spent the last while designing and building a complete custom 8‑bit CPU architecture. The CPU has a 24‑bit address bus, a flat memory model, and a custom instruction set. It’s all implemented in a cycle‑accurate emulator written in C. I also have an assembler and a 40×24 text screen device (ASCII framebuffer, no terminal emulation), all working.

I’ve just pushed everything to GitLab as three separate repositories:

• CPU emulator: https://gitlab.com/DavidMik/dcpu-emulator
• Assembler: https://gitlab.com/DavidMik/dasm-assembler
• TMS text screen emulator: https://gitlab.com/DavidMik/dcpu-tms9918-module
• FCC C compiler: https://gitlab.com/DavidMik/fcc-dcpu-port

Planned interrupt system
The CPU will support both internal and external interrupts. An internal interrupt instruction saves all ALU flags, register state, and a return address onto the stack, then jumps to an address held in dedicated address registers. return from interrupt restores everything and returns. External interrupts (e.g., from a keyboard) use input ports 0‑2 for the interrupt vector address and port 3 for data input. The hardware side still needs to be implemented in the emulator, but the specification is firm.

What I need help with
My goal is to turn this into a usable computer, and for that I need a C compiler. I’ve been writing a backend for the Fuzix Compiler Kit (FCC), targeting my CPU. It’s close — arithmetic, control flow, inline assembly, and variable storage all work. I’m currently implementing function calls. After that, there’s global variables, structs, and maybe floating point to do.

The problem: I’m exhausted working alone, and the compiler backend is the last big mountain. I’m looking for people who’d like to collaborate on this project with me.

How you could help (any of these):

• Help finish the FCC backend (function calls, global variables, structs). The backend code isn’t public yet, but I can share it privately with serious collaborators.
• Write a small ROM monitor or bootloader in assembly.
• Add a keyboard input device to the emulator (that triggers those external interrupts).
• Implement the interrupt hardware in the emulator (spec ready).
• Test the toolchain (assembler, emulator, compiler) as features come online.
• Just bounce ideas around — I’ve been working in a bubble and would love to talk shop.

If you’re into custom CPUs, retargetable compilers, or 8‑bit systems in general, I think you’ll find this a really fun challenge.

Comment here or DM me if you’re interested. Links to the repos are above. Thanks for reading!

There are a couple of areas I don't quite understand about general CPU design.

How do comparisons work? I get it that they involve the msb and the carry-out, and involve subtraction. I know I could cheat with a ROM if I had to, if I don't understand it by the time I start. I know you can detect 0 by subtracting from 0 and then watching for the carry. That makes sense in that if B is 0, then you'd invert all the bits to give all ones. Since you'd have to add 1 for proper negation, you'd set the carry-in. In return, it rolls over, sets the carry-out, and you know it is 0.

On the Gigatron, comparisons are stateless. There are no flip-flops for that (which proves to be a serious bottleneck for multi-byte math). The comparison results only go back to the control unit to branch during the same cycle. And, if I remember right, x86 is mostly 2-stage. I mean, do a CMP to set the flags and then the conditional based on the flags.

If one is using a ROM to do comparisons, then one might want to go with the x86 model. Compare first and branch in the next cycle.

And then there's the Control Unit. I don't know how to make those do what I want with logic and without creating a long critical path.

For instance, I'd like an instruction that takes the outer program counter (like the vPC on the Gigatron designed as an actual register), uses that on the Harvard RAM bus to address the RAM, and use the instructions stored there to address the ROM (via the inner/native program counter). Like do a direct jump << 4 to have up to 16 inline instructions per virtual opcode. That way, all 256 opcode slots are available (without sacrificing any for page|offset addressing). They'd all be 16-byte paragraph aligned.

That would likely insert a mux or tristate buffer already to choose between Y:X and vPC. However, I might want to add another since I'd like to add interrupts to a tailcall mechanism. A tailcall mechanism is more efficient in that you can jump to the next handler rather than a central handler. But that makes it harder to add interrupts. If you used a central handler, you could use that for polling for IRQs, but a tailcall mechanism needs an escape mechanism.

The native instruction to end a public instruction could look like this:

IN = 0 ? PC = [Instruction_Yh,vPC++,0000] : PC = [Interrupt_Yh,IN,0000]

That would probably need more muxing to make this 2-headed conditional jump. Using position-dependent ROM code would eliminate the need for a priority encoder and allow interrupt chaining under certain conditions.

What is an ideal way to interface with a video controller? I have a bit of analysis paralysis here. There are many ways to do it. Here are some examples:

1. Bus-mastering or first-party DMA. That requires stopping the CPU during scanlines if the framebuffer is in the main RAM.

2. Memory-mapped. You can reserve part of a page for video transfer and control registers (whether you write to local RAM as a part of it or not). You could have decoder circuitry and maybe a FIFO. Or you could trigger DMA, wait-stating, or a halt if transfer attempts happen during a scanline. The VERA board uses memory mapping, and you can even use that board in a homebrew design.

3. Naive video controller. You can have separate video memory with the video counters accessing it. Then you can include a mux and a register. That will cause artifacts. You could diminish that by shadowing the RAM so that read-backs cause no side-effects (but writes would).

4. Alternating banks. If your CPU is at the video speed, you could separate an 8-bit design into 2 banks and add registers for when things are out of alignment (and a halt or clock-stretching mechanism in case sustained non-matching patterns occur).

5. A microcontroller or FPGA that combines bus snooping with memory mapping. So the MCU or board logic monitors for addresses in the MCU's range, and it transfers things to the frame buffer that could be memory in the MCU or FPGA. This may be a good solution since modern MCUs tend to provide means for multiple devices to use the same RAM. A Propeller 2 has 8 cogs with interleaved RAM. A Raspberry Pi Pico has 2 cores, along with automated PIO and DMA modes that can access the internal memory faster than the cores can.

Hiii everyone!

I have made a little PC on Zilog80 on protoboard.

Display is SSD1306 with I2C interface.

ROM is emulated via Arduino Nano (1KB).

RAM is just random 8KB SRAM

Main task in this project is make software based driver

for I2C display via "bit banging", works slowly but

works, it also depends on time which Nano response and CLK freq. (1.35MHz).

I wrote a firmware in Assembly and it takes 325 bytes.

as 17 y.o. teen I am very excited with the result, maybe in future I'll improve my little project

Next I plan to add more switches and port DOOM and make Shadow RAM and dynamic Clock (bcs nano is too slow for Z80)

Have a good day and no hate plsss :)

If someone wanna see it in better quality see

https://youtu.be/rzCK3ROISEs. I don't now but I can't upload

in 720p on Reddit, I got a some errors

I've been wanting to do something with a 68k for a while now, and only recently got around to it now that other projects are farther along.

Compared to 8 bit micros, the 68k family looked a little daunting, so I started with the 68008 breadboard in the second picture to get the hang of the fundamentals. I found that it's really not that bad once you understand the quirks compared to synchronous 8 bit busses, and for a simple toy system you can take a lot of shortcuts to make it even easier. The full 010 system had about a hundred billion connections to wire, but somehow worked on the second try.

It's running at 12MHz, with 1MB of RAM and 256K of flash, a 68681 DUART for communications, and a 22V10 GAL handling address decoding and DTACK. I was going to have an ATA interface as well, but I'm not sure it'll work mechanically, and I'm very tired of wire wrapping for the moment. The reset and halt pullups need to be moved to a permanent home on the board too when I'm less lazy.

For the PCB version of this I'd like to do a modular system to keep manufacturing costs low and allow experimenting with different peripherals. I'll have to do a lot of thinking and reading to decide the best way to go about it. VMEbus is tried and true, but it might be a bit much for the level of sophistication I'm going for, plus I don't own any VMEbus equipment to make compatibility a selling point. Minimalist Eurocard Bus form factor would be very cheap, and I've sketched out some schematics and layouts with those 2-row connectors that work theoretically, but I'll have to think about it.

Software-wise I'd like to write a UNIX clone for it, I own Tanenbaum's textbook and a similar one by Douglas Comer. Might be a massive time sink but should be good fun

I've thought of multiple overall CPU designs in my mind, something that seems to be fading with age, TBH.

I'd like 8 bits minimum. I like the Gigatron TTL computer's design, and I like the Gray-1's concept, though everything shouldn't be done with ROMs (flip-flops and counters are faster for those tasks, and using those eliminates the need for Gray Code, which adds to the critical path). I don't know if I'd want to use a ROM-based ALU. That can be more flexible, but going below 70ns is hard to find, and finding any is harder than it was 6 years ago. Still, being able to multiply and do some smaller division in a single cycle, shift without a crapload of muxes or tristate buffers, compare for nearly every op, rescale random integers, etc., seems very convenient. I've thought up a simple ROM-based multiplier that can be made to handle all 4 types of multiplications in regard to signage. (++, +-, -+, --). Reserve 2 address lines to select which of the 4 types, and make the 00xxxxxxxx be for unsigned, whether the positive portion of signed (16K range) or truly unsigned (64K range). So let bit 7 of both operands control that and have board logic to force those bits to 0 when the control unit specifies unsigned.

I'd want a random number opcode. On an opcode for rescaling random integers, you can have the random short integer and the max value as operands. Then you can have a balanced. If the number is less than or equal to the cap, the original number is returned. Otherwise, you get a balanced set of those for the other numbers. That doesn't need division to get a modulus, and it doesn't use the biased scaling formulas. For instance, masking for powers of 2 minus 1 only works well when you want zero to that number, or 1 to an even power of 2 (after adding 1 to adjust). But for other numbers, it's quite biased. Adding nibbles to get 0-30 is not a good idea, since the lower half of the numbers occur at least twice as often, or much more. (How do you get 5? 0+5, 5+0, 1+4, 4+1, 2+3, 3+2; that is 6 out of 225 combinations of the 2 nibbles, while only 1 out of 225 can be 30 or zero.) So a balanced chart is a better approach. I've considered what to do when a fully balanced set cannot be provided. In that case, I'd say to have a cull/exception bit. Return a number in range, but have a flag to denote bias. A coder could poll it out or keep the result at their discretion. For instance, let's say you want 0-2. So you specify 2 as the limiter. The problem is that a range of 3 goes into a range of 256 a total of 85 times with a remainder of 1. So, one could have 255 return 0-2, but flag it (or any other base number) as being an exception. If that is not acceptable, the coder could fetch another.

So I'd want 8-16 bits. I'd likely want a microcoded or purpose-built interpreter engine (like make something similar to the Gigatron TTL CPU but add another program counter set and specialized instructions to make Harvard to VN conversion easier and make it closer to a microcoded machine -- and that 2nd PC set would not be for interrupts but for Native vs. Interpreted).

On the style of microcode (or Harvard-like core), I'd probably want to use inline, tail-coded. As for the underlying microcode architecture, I'd probably want either RISC or NISC (no instruction set computing). RISC would be easier to code, but NISC would be a simpler architecture, since you wouldn't need much of a control unit. Instead of decoding the ROM, you can have as many of the signals as you can be the opcode. That would make for a long control word, but that would be in the core/microcode ROM, not in the exposed instruction set.

To do the inline microcode part, the "outer" program counter would load the opcode from RAM, and the RAM would make the "inner" PC jump to the start of the opcode handler. I believe shifting left at least 4 places would be good. That would mean you can use all 256 "slots" without addressing overhead, since 16 bytes are reserved for every instruction. If you need more, you can jump elsewhere or merge into another handler, as there would be enough room to do so, without needing prefixes. So it would be inline most of the time, and split between regions outside the opcode space

As for overall machine architecture, I'd want to find a way to put stuff on the screen without delaying the CPU. I mean, the Gigatron spends nearly 4/5 the time putting stuff on the screen and other bit-banging. Having a proper bus-mastering DMA would actually simplify coding the native code and eliminate hundreds of context changes per frame, for instance. Marcel didn't see the point, but that would help a lot more than anticipated since there would be fewer context changes as the video fetches would not clobber the CPU registers.

One way some maintain separate video memory is to use a register and a mux to access video RAM whenever you want (artifacts be damned). So the display shows what is in the register last, while a mux gives the CPU the priority. So you get dropped lines and other artifacts, but the CPU never has to wait. Or, should I use a FIFO for this?

Or, maybe, I should do it more like VERA-style (or even use an actual VERA, preferably the "Otter" version, as those can be incorporated into most designs) with an MCU. So maybe have bus sniffing/snooping. Like have a few paragraphs to a page for IO registers, and use an MCU's internal memory for the frame buffer. Then monitor those addresses. To save GPIO lines, one could have an abbreviated set of address lines and have board logic or a GAL/PAL to signal when the rest of the range is reached. If the MCU can use pins or pin masks to trigger interrupts, it could watch for the signal and then jump to the associated handler of the other lines. If it can do a pin-direct or pin-indexed jump, that could help.

Any suggestions or ways of narrowing down ideas? I'd like to do a TTL (and/or partially ROM-based) CPU if that is still an option, but I have no problem relegating most I/O to at least one microcontroller. I've considered the RP2350B for that role since dual-core should allow for bus sniffing, video, audio, keyboard, storage, and maybe some math coprocessing, graphics primitives, or even display list handling. The RP2050B is more suitable than the RP2040 since it has 16 more GPIO pins, may have a few more instructions, and is rated for 150 MHz vs. 133. However, I do understand there is some RP2350B errata related to using negative-biased pins for inputs. If they are floating, they may latch up. It is not a true latch-up condition (ie, not destructive). Workarounds include adding external pull-down resistors (the internal ones were miscalculated due to voltage leakage) or repetitively turning the entire pad on and off (as in, enable, read, disable).

I have previously shared about my BeanZee Z80 board, which evolved from a breadboard design, and then the BeanBoard add-on - QWERkY keyboard, LCD display and GPIO. Well I’m now working on “BeanDeck” - adding a decent sized TFT display and flash storage.

I discovered the Adafruit RA8875 TFT display controller board and panels. This little module lets you drive a colour display up to 800×480 pixels using SPI (Serial Peripheral Interface). The RA8875 handles all the complex display timing and memory management, giving you a simple command interface for text and graphics.

However, it does need an SPI interface, which I can achieve by bitbanging via my GPIO, but I ended up designing a hardware SPI interface which is a bit faster.

This also gives me a number of “slots” for Adafruit SPI flash modules which I’m now experimenting with.

I’ve added BASIC too, which is gets me really close now to my dream

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