6502.org

Thanks. I and my students will look into it.
Which version of the circuit is the most recent one, the one currently at GitHub (shown below left) or the one described in the documentation (Breaking NES Book 6502 Core Rev. B4) (shown below right)?

Both are an approximation of what is actually there.
Logisim does not support bidirectional connections, which are used in large numbers at the bottom of the processor (buses).

The one in the book contains no special "hacks" to handle bus conflicts.

You need to figure out on your own how best to simulate bidirectional connections in your program if it does not support inOut entities (in Verilog terms).

It is best to read carefully what is written on our wiki, I think all questions will disappear naturally

@org, okay, thanks!

First of all, great work!

I stumbled upon a few things while recreating the schematic in KiCad/eeschema which I thought would be nice to share.

First, I noticed that the output databus is latched at the end of phase 1. That's apparently how Logisim RAM works. This is not the same as real hardware where the transaction takes place during phase 2 and ends when R/W goes high again.

Secondly, I noticed that the transfer of SB to AC on PHI2 only seems to work because of a hazard that occurs in Logisim. SB/AC and PHI2 are not supposed to ever be high at the same time, but there is a small window when PHI2 goes high before SB/AC goes low again.
This is a side effect of Logisim's simulation. Other simulations I ran (LCC, another ED simulation, and Verilator) failed to latch SB into AC. I fixed this by latching on SB/AC directly.

Thirdly, the BCD correction does not work. I traced it back to the following wrong connection:
/carry3 connects after the AND port. After that, the full 6502 Dormann test passes!

Hello everyone! I would like to present my version of the 6502 project in Logisim. It is different from what was previously published here @Org. I had a slightly different approach, first of all, I got rid of all the tristates inside the design, except for one that controls the output data flow. I had to tinker a bit with the data transfer between buses. It even works with Klaus Dorman's tests. However, I did not wait until it passed the entire test, I have to leave my laptop on for too long. Based on this project, I wrote my Verilog model of a clock-accurate clone of the 6502 and successfully launched it as part of the NES 2a03 core. The source codes are in my GitHub repository, and there you can also find small photos and video reports on the work done. https://github.com/andkorzh/BREAKS6502

Welcome! Looks like a splendid bit of work. And congrats on your verilog model passing almost(!) all tests!

Thanks!

Welcome, and I'm curious to see how quick it is at a tiny basic - my 8080 model takes about five minutes to count from zero to ten...

Neil

Thanks Neil!
Logisim produces approximately 150-200 clock pulses per second on this scheme, you can roughly calculate the performance. But when modeling in Logisim PPU from NES, one frame of the image was rendered for 35-40 minutes, depending on the speed of the computer.

/me wags tail

I'm curious - in my copious free time - to convert the design to Digital, which I've just started playing with. That has a lot more 74xx parts as primitives, though I'm not sure if it has all the ones I need.

The 8080 was a lot faster - perhaps double the speed - using Logisim primitives, but I was using it to test the TTL circuit. Which one day I might even build. There don't seem to be many TTL 8080s around.

(The design is definitely not clock-similar; some of the instructions take a cycle or two less - though the longest is still 17 IIRC - but it has a 6502-like bus interface, with no access to the memory when the clock is low phase.)

Neil

Video on YouTube: https://www.youtube.com/watch?v=dFyq43pBDUY
You can see how the blocks move inside 6502.

I managed to successfully complete the Klaus Dormann test on my MOS6502 model in the Logisim environment. The test was started on 08.08.24 and was completed 12 days later. The previous attempt was unsuccessful and small bugs were found in the decimal correction scheme. And after they were fixed, the test was successful.

well done! A marathon achievement!