u/MindlessExplorer2845

The wire provided in the 6502 kit is perfect in dense wiring required in projects like 6502. I had 22 AWG before, but apprantly that was too thick. I recently bought 24 AWG, but apprantly it is still too thick.

In Ben's video, he says the hsync and vsync are active negative. However, I searched the standard, and it says active high (positive). Anyone knows what is happening?

https://preview.redd.it/x7v9p7oz8kmh1.png?width=1105&format=png&auto=webp&s=2c327d35d4736004b1036975a89ea911da043a2b

https://preview.redd.it/lwgaix859kmh1.png?width=850&format=png&auto=webp&s=42c43b9b811ef2e1f67214ed231572db79860526

Also, the standard says a new line starts at the beginning of the sync pulse, not the active video. It matters when we are considering when exactly the vsync should be active, relative to the hsync signal.

https://preview.redd.it/gxk6hl9n8kmh1.png?width=1112&format=png&auto=webp&s=41a05d5b01c49b54276563744d2a7056b3800dd7

document:
https://glenwing.github.io/docs/VESA-DMT-1.11.pdf

I just built the 6502 breadboard computer, and MSBASIC is working on it right now. Unfortunately, I don't have experience on MSBASIC. In fact, the first time I've touched a computer it was Windows XP. Any tutorials on MSBASIC? Otherwise I feel like I am pretty limited on my breadboard computer, other than blinking some LEDs and showing some text on the LCD.

I was working on the 6502 computer, and the hello_world program kept giving me headaches. Seems like some code works and some doesn't, and everything was so weird. Eventually I found out that sometimes the same code doesn't work anymore.
Turns out there was a faulty connection between the EEPROM and the breadboard. I had two ways to insert the EEPROM into the breadboard, and only one of them have good connection.

To be fair, I was inserting more than one pins of a transistor into a hole before. Maybe I should never do that.

In Ben Eater's video "RAM and bus timing -- 6502 part 6", he explained his solution on satisfying the timing requirement. However, I don't think the solution is robust. I think it is not guaranteed to work.

First, let me state his solution:

Invert A15 through a NAND gate, then NAND it with the clock, before feeding it into /CS.

Consider a write cycle. The requirement for the SRAM is that either /CS or /WE is high at least 0ns before the address become invalid. However, from the datasheet we know that the address is guaranteed to be valid at least 10ns after falling of PHI2. Assuming A15 always high, then /CS is rising typically 8ns after the falling of PHI2. However, /CS is only guaranteed to rise 15ns after the falling of PHI2, at which time the address bus may have already changed. Even if we are using the typical 8ns value, it is cutting extremely close with 2ns to spare, considering the fact that light only travels 1ft every nanosecond.

I have another question. Consider the read cycle. The datasheet requires data to be valid at least 10ns after the falling of PHI2. There is no guarantee of minimal time of the propagation delay for 74HC00, so I guess it is 0ns. Therefore, /CS would go high, in worst case, 0ns after PHI2 falls. Assuming /OE is low during the process, we shall refer to Read Timing Waveform (3) of the datasheet, which says that it takes minimum of 0ns and maximum of 20 ns from /CS going high to Data being high-Z. Therefore, is there a chance for the read data to be invalid?

I think a more robust solution may be to use a 2MHz crystal oscillator and a binary counter to generate the 1MHz clock, and use some logic gates to let /WE rise at the midpoint of high phase of PHI2.