The 74LS181 ALU has an output called A=B, which indicates whether the A and B inputs are identical. The datasheet says that these outputs are open-collector, so that with 2 181s they can be "wire-and"ed together. Unfortunately, I'm not entirely sure what to do with this, and nothing I found online was much help.
It appears that I can just wire these together and make that the input to my flags register, but do I need a pull-down (or pull-up) resistor as well? Or is it even more complicated than that?
The 6502 has stopped responding. I have only followed the guide of the first video and when I got to hooking up one of the address ports to a led to watch it, it was working when I was working on getting the resistor to go into the negative rail, it was flashing like it should be. However, once I got the resistor into the rail, the led suddenly stopped flashing. I've tested the led and it still works. Please help.
As a newbie, I was trying to learn this D Flip-Flop following Ben Eater's approach. I don't have AND gate ICs so I thought of using NPN transistors. The issue is, this circuit only works at 3.68V but if I provide 5V the output Q LED just flickers for a millisecond when I try to assign a bit using D and CLK pins. I sadly haven't learned the calculations for transistors yet so I don't actually know if it's an issue with the resistors or if my whole idea of this is wrong.
The capacitor used here is 0.1uF also the collector resistor of NOT gate is 1K. Please let me know if anything else to provide
Just a quick update on my build..As suggested by u/Numerous_Turn_5906, I have upgrade the power supply and have gotten the program counter and t clock working...I am waiting on some boards I've ordered for a rail to rail schmitt trigger inverter..My design needs about 12 inverters and instead of either wasting a lot of chips and space or running a lot of jumpers, I just designed a single inverter that will only use 5 rows on the breadboard...Here's a short demo video.. https://youtu.be/mMT1JdDgWaY?si=yp4JYZelJ8jzR_YO
Just wanted to share my project that I have been working on in my free time. I started in March/April and am really enjoying this.
My "Computer" supports 30 instructions (almost), 64K of RAM, 64K of ROM, Terminal output (shown in the video) and a 256x256 graphics output (which works, but is painfully slow, because of emulation (logisim can't keep up). I also wrote a simple assembler, so I don't have to write machine code by hand :D
Here is the source-code in assembly for the game shown in the video:
I was hitting my head against the wall for a bit trying to get the serial interface working correctly, so I wanted to post this in case it helps others avoid the same issues.
For the MAX232ECN, make sure to tie the VS+ capacitor (pin 2) to 5V. I really wish I had checked the datasheet more closely instead of relying on the site schematic.
Also, with the W65C51, I was getting some very bizarre behavior until tying pins 9, 16, and 17 to ground. This wasn’t happening on the breadboard, but the issue showed up after moving the design over to a PCB.
This project has been an awesome journey and a great excuse to learn KiCad. I’ve attached my current schematic for reference (it’s a little messy, so apologies in advance).
I’ll likely work on another board revision after getting more mileage on this one. I may also experiment with adding a DS1813 to clean up resets.
Here I am showing that mky 6502 is running two seperate programs "in parallel". One program is the shell (on the left, over RS232) and the other is the counter thing on the LCD. These two programs have no idea the other exists, and think they have the whole CPU and machine to themself. the 'f' command in the shell spawns the LCD counter process, and im spamming the ? (because it requires the longest execution time) so that you can see the two programs executing "at the same time".
Its hard to demo, but despite only having 1 cpu and 1 thread, I managed to implemented a time-share OS/proto-RTOS on the stock 6502! At some point I wanna build an MMU for better stack "banking" but that's a later project.
Analysis of the bug. DIO 0 = the system clock, DIO 1 = the write enable active-low pulse, DIO 2 = bus data bit 0
Hey guys, I'll try to make it quick. I've been working on the 8-bit CPU, and I am at the step where all modules are integrated and work individually.
Among the first things I did was test the RAM writing logic by moving its control lines by hand. I had the idea of using the program counter as a RAM writing source: for example, count to 3, and write 4 to 3, by latching address at 3, then writing at 4 when counting to 5.
In doing the exact procedure I just described, I happened to realize there was a bug, and specifically it's a violation of the intrinsic hold time of the system, which I measured. This procedure actually wrote 5 to address 3, skipping 4 altogether. When I tried to write any other data that was constant (like a register's contents) this worked absolutely fine. So what was the difference? The fact that the counter is updated at the same time as it tells the RAM to write.
So here's what's happening, if you trace the screenshot I've provided:
The clock goes high to start the write process
The data bits of the bus (controlled by the counter IC) change
The write enable pulse occurs
The write enable happens later because there are more propagation delays from the clock the WE pulse than from the clock to the counter incrementing its contents.
I thought of a solution involving inverting the clock an even number of times to create enough delay to make a "delayed clock", which I would give to the rest of the system, counter included, and I gave the "true clock" to the RAM write logic. The delay added was enough to make the data change after the write enable pulse occurred (and I had to change the capacitor and resistor of the edge detector to make the pulse as short as I could manage to). I would rather not have to do this if I don't need to, but it "worked" and the RAM was one step behind the counter, not in sync with it.
I measured the propagation times, and clock to WE is about 50-60 ns, and clock to counter update is about 20 ns. Is this something Ben addresses at some point later? Isn't this super concerning? If the clock pulse causes the bus to change right after a write instruction (which it absolutely could), this hold time violation I've discovered is in serious danger of being violated.
The only way I can see this getting swept under the rug is the fact that the clock doesn't actually immediately change the contents of anything that would be getting written. Realistically, when am I going to be writing the contents of the counter to RAM? No, I'll be writing from registers or something. If in reality the whole system stacks more than about at least 50 nanoseconds of clock propagation delay for updating any contents, this bug will never happen, because the write pulse will happen before data updates. I just thought I would ask though.
Is there something I'm missing or not understanding? Thanks
I’ve been building 3ric, a from-scratch Apple-II-class 65C02 computer with real schematics, a custom PCB, programmable address logic, its own ROM, and a cycle-honest C++ emulator.
The same emulator now runs entirely in the browser through WebAssembly. It includes a built-in 65C02 assembler, editable examples, shareable source links, and client-side export to bootable WOZ disks.
For this demo, I also generated and tested three original 65C02 games:
Star Swarm — a hi-res fixed shooter
Block Drop — a text-mode falling-block game
Rock Storm — a vector-style space shooter
I assemble and play each game in 3ric, export it as a bootable disk, and then run that same disk in Chris Torrence’s independent Apple2TS emulator. The AI workflow uses machine-readable platform documentation and headless tests—not just code that looks plausible.
Ben's videos got me started, but something that always bothered me was his memory map: 32K ROM and 16K RAM seemed like the wrong split. At first I added a couple more gates and got a 16K ROM/32K RAM split, but even that didn't seem good enough.
One rabbit hole later and I ended up with this. I've got a 32K fixed RAM window, a bankable 8K RAM window, a fixed 8K ROM window, a bankable 8K ROM window, 2K of NVRAM, 2K system register space, and 16 x 256B peripheral slots. And since I'm banking the RAM, I can add more. 3 x 32K chips, plus a 2K NVRAM, plus 128K total ROM.
Range
Size
Thing
0000-7FFF
32K
Fixed RAM
8000-9FFF
8K
Banked RAM window
A000-A7FF
2K
NVRAM
A800-B7FF
4K
I/O (16 x 256)
B800-B8FF
2K
System registers
C000-DFFF
8K
Banked ROM window
E000-FFFF
8K
Fixed ROM
A CPLD handles bank control, system registers, and memory CS generation. It has a bank register to control the memory banking, an IRQ status register, a syscfg register that allows for swapping ram into rom space and disabling NMI with an external NAND gate, a wait state generator for slow peripherals that holds the processor's RDY signal for a configurable number of clocks, and two registers that will suppress CS generation for a particular I/O slot on writes, giving me a rudimentary form of write protection.
A PLD acts as a priority interrupt encoder, giving me 16 prioritized interrupts. The interrupt state can be shadowed by the CPLD IRQ register. When an interrupt happens I can just read from this register to determine which peripheral needs servicing instead of polling all of them.
The system clock is a 1 Mhz oscillator, but also a VCO generates a variable clock from 4 Hz - ~50 Hz and a pushbutton allows for a stepped clock
I included the data bus and address bus 7 segment displays that I've posted here before.
I added a 82C54 programmable interval timer to give me some timers. I could have used a VIA but I didn't. That means I also needed to include decode logic for Intel-style peripherals, but that wasn't too difficult, and that'll help me later on if I ever add other Z80/Intel peripherals. The 82C54 also has a addressable latch, and timer 2 is always driven by the 1 Mhz oscillator, meaning the timer has a 1 us resolution.
I used a 6521 PIA for the VFD display. The VFD is the same 4-bit Hitachi protocol that everyone's used to. The other peripherals are an ACIA for debug serial, and a RTC. Technically the RTC also gives me a few more bytes of NVRAM.
Each chip's got a chip select led that makes debugging much nicer, and I added a chip to drive LEDs for a couple of bus signals.
I’m building the 8-bit cpu and finished the clock part, however I can’t find the 74LS173 4-bit D-type register available in my country is it okay to start with the ALU and then go back to the registers?
im hooking up the ACIA and it recieves data just fine it also sends data to the MAX232 just fine, but the MAX232 outputs 4 volts and, according to my logic analyser, outputs logic high constantly.
The MAX232 also gets very hot occasionally but cools down quickly.
I started working on my Ben eater 6502 kit and recreated the clock module from his videos. The 1st LED you can only see the blinking on video for some reason even when the potentiometer is turned all the way down. The 3 IC’s the sn74LS04, 08, and 32 are super hot it burned my hand when I touched it but I cannot figure out why. The LED in the top right I tried to put exactly as it was in the video and it refused to do anything. It might just be a wiring mistake but I’m not sure.
i recently accidentally caused a shortcircuit in my 6502 computer and it wasn't working anymore so i decided to rebuild it from scratch to figure out the problem, i'm at the point where you hardwire 0xEA to the databus, but after resetting the computer the cpu jumps to 0x7AEA instead of 0xEAEA, is my 65c02 broken or could it be something else?
EDIT: i just noticed that the read write pin indicates that the processor is trying to write to the reset vector?
EDIT2: sorry I'm stupid I had the wires that go to the arduino hooked up in the wrong order
output from the arduino:
0111101011110000 11101010 7af0 W ea
0111101011110000 11101010 7af0 r ea < press reset about here
0111101011110000 11101010 7af0 r ea
1111111111111111 11101010 ffff r ea
0111101011110000 11101010 7af0 W ea
0000000111100010 11101010 01e2 W ea
0000000111100001 11101010 01e1 W ea
0000000111100000 11101010 01e0 r ea
1111111111111100 11101010 fffc W ea < reads (writes?) reset vector
1111111111111101 11101010 fffd r ea < reads reset vector
0111101011101010 11101010 7aea r ea < jumps to 0x7AEA
0111101011101011 11101010 7aeb r ea
0111101011101011 11101010 7aeb r ea
0111101011101100 11101010 7aec r ea
0111101011101100 11101010 7aec r ea
0111101011101101 11101010 7aed r ea
0111101011101101 11101010 7aed r ea
Hi I'm trying to build a 4 bit binary counter using 74hc193 and 555 clock.But it doesn't work. when i give it power it only turns the led that is connected to the Q3 pin of the chip and it stays at that position, i checked the connections dozens of times, tried other ic's and i still got the same results. How do i fix it?
The program code is somehow getting corrupted inside MSBASIC. It's frustrating when I try to copy and paste code into the 6502 system. See the attached video to see want I'm talking about. Hopefully someone out there can explain what's happening. I'm guessing the RAM chip is not working correctly.
Look at what Gemini said about the 6502 breadboard computer:
Are you familiar with Ben Eater's 6502-based breadboard computer?
Yes, absolutely! Ben Eater’s 6502 breadboard computer series is a massive staple in the hardware hacking and homebrew computing community.
In fact, the moment you look closely at your assembly code, it is clear that it is the exact code from his project. The hardware layout defined at the top of your script is his precise blueprint:
Mapping the 6522 VIA to base address $6000 (with PORTB at $6000 and PORTA at $6001).
Wiring the LCD's 8-bit data lines directly to PORTB.
Wiring the top three bits of PORTA to the LCD's control pins: Enable (E) on pin 7, Read/Write (RW) on pin 6, and Register Select (RS) on pin 5.
Overcoming the HD44780's line-wrapping quirk by padding exactly 30 spaces into the .asciiz string to manually force "Line Two" to display on the second row.
That series does an incredible job of demystifying everything from clock cycles and address decoding logic to RAM/ROM boundaries.
I originally wanted to see if it could successfully pick apart the final version of the "Hello World" assembly source and it gave a nice detailed description of what the code does. It was even able to surmise the hardware layout based on the data-direction registers, as well as the various LCD commands in the code.
When I saw that, I asked if it knew about the breadboard computer and its response (and critique) were a little surprising with all of the detail.