• Content Count

  • Joined

  • Last visited

About steddyman

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I want to take this project on for two main reasons. 1. I loved the C64 back in the day and still enjoy using it today. 2. I want a much better quality video signal from the C64 on modern hardware. The above two reasons I expect to drive me through any frustrations of learning electronics and VHDL, whereas something I don't have an emotional investment in won't. The VIC-II has never been reverse engineered and any knowledge of it is based on observations of software running on the C64. I don't expect to ever make any money out of this and will likely Open Source the project once I have something to share. But I've already spent months doing it, and haven't given up yet
  2. Thank you both again for your incredible patience in still answering my questions. The TI spec sheet also states the following: 'Supports Mixed-Mode Signal Operation on All Ports (5-V Input/Output Voltage With 3.3-V VCC)' My circuit isn't interacting with the VIC-II, it is replacing it but I understand your point. It is interfacing to the 6510 and logic chips on the C64 motherboard which would be the equivalent in your statement. What I don't understand is your statement 'pulling the outputs on that side to 5v'. Do you mean when my circuit is driving a logic level 0 to an input on the 6510, that the 6510 will be pulling that to 5v? TI do a dual rail voltage version of the 74LVC245 which is called the SN74LVC4245 which has a 5V and a 3V side designed for driving CMOS. But, my observations of the voltages on the original VIC-II don't show it is incompatible with the output ranges of the standard version.
  3. Apologies, I think I'm not describing myself well here. There is no FPGA involved in this scenario. This is an original working C64 with an original working VIC-II chip showing those voltage characteristics. My FPGA circuit will replace this chip, but everything is buffered to the FPGA using 5.0V tolerant buffer IC's.
  4. What this means is that if I put my Oscilloscope GND lead on the GND pin of the VIC-II, and the probe tip on an input only signal on the chip, I see signals that alternate between 0v and 5v, with low signals at closer to 0v. When I do the same test on an output only signal, I see the high signal level at around 3.5v. I've don't quite a bit of research on NMOS, and it is an N-type MOSFET which is still popular today with the same signal levels and noise margins as CMOS. My purpose here is not to re-produce the C64, there are plenty of projects that do that on an FPGA. The purpose is to re-product the VIC-II for original C64 owners but with enhanced features and connectivity.
  5. Thanks. Yes, I am using the 74LVC245 to provide direction and a tri-state bus via the OE pin. I'll take a look at the timing of switching between sending and receiving data. Oddly the 74LVC245 data sheet shows that the maximum output high voltage is VCC + 0.5V which I would have expected to be VCC - 0.5V. However, can you explain my obvervations of voltage on the original NMOS chip. Voltage ranges for outputs appears to be 0 -> 3.5V. Voltage range for inputs appears to be 0 -> 5V. This is the reverse of this guide:
  6. Thanks Zygot No, there really is no time when the bus doesn't have the potential to be driven. Normally the CPU (6510 which is a 6502 variant) drives the address and data bus when the clock signal (also generated by the VIC II) is high, and the VIC II drives the address and data bus when the clock signal is low. However, there are some conditions that cause the VIC II to to hijack both cycles of the clock. I'm testing in circuit so it is very difficullt to simulate a small part of the functionality. However, I think I might have an idea what is happening, which is unfortunately going to require a rework of the circuit. I've realised that the 74lvc245 is quoted as 5.0v signal compatible, but on closer inspection that is with TTL only. The VIC II and the 6510 are NMOS, which means they are CMOS signal levels. The high level signal output of the 74lvc245 could be as low as 2.7V, when I've observed it is closer to 3.3V. However NMOS inputs require a minimum of 3.5V to be considered a high signal. So while it is fully compatible for inputs from the C64, it is borderline compatible when sending signals to the C64. I'll have to swap to using the dual voltage rail version of the chip. What is very confusing for me when probing the original VIC II chip when in circuit, is that outputs tend to be high around 3.5V and inputs tend to be high signal levels at around 4.8V. That's the opposite of everything i've read that says Voh is 4.8V and Vih = 3.5V for CMOS. Based on the measured voltages of my FPGA circuit emulation of the chip, my outputs signals are around 3.3V but with noise spikes of around 200mV above or below.
  7. Ok, thanks for the quick response. The only pins on the CMOD A7 currently not connected to anything are pins PIO15 and PIO16 (ADC) and PIO18. I don't currently have those set to outputs because I wasn't sure if the ADC could or should be set that way, and only recently stopped using PIO18. I am actually trying to recreate the C64 VIC II chip using an FPGA. This is interfaced to the original socket on the C64 main board and outputs are buffered by 74LVC245's. The complexity is the VIC II can become a bus master so voltages can either be flowing in from the C64 or flowing out from the Cmod A7 and normally the VIC II controls the bus on the negative edge of the clock, and the CPU on the positive edge. I'm really struggling with this and close to giving it up. I am probably reading ground noise all wrong, so maybe getting false positives. I was reading the GND noise by connecting the GND lead of the probe to the GND near the chip on the C64 board, and then putting the probe signal lead on a GND on my board at various points. I was seeing at worst around 1.2 V differential but usually around 700 mV. The actual issue I am facing is when using a logic analyzer, I am seeing frequent transitions to HIGH where there should be none on the BA line (PIO21) being fed into the IC socket from my board. This output signal is fed by a clocked reg, but the transitions are much faster than even the internal clock pulses. The false signals are usually at the minimum duration you would expect based on the sampling frequency of my logic analyzer (200Mhz). My internal clock that drives all the other logic is only 40Mhz and the transitions are much shorter than this. This led me down the path of noise, but I've exhausted my knowledge of the cause now.
  8. Can I ask what the reason for this particular recommendation was? Every other thing I have read suggests I need my inputs to have the SLOW slew rate, and driving minimal mA to prevent strong voltage swings.
  9. Thanks, yes I have the DONT TOUCH attribute on all my input / output pins. I added those some time ago because I noticed Vivado was sometimes optimising them out of the design. I've checked every external IO pin in the Schematic of the Implementation, and they all have the correct BUF primitive assign to them. With regards to the runt pulses I see on the logic analyser, I see non of these in simulation so I am confident it doesn't relate to an issue with combinational logic. Also, their length is much shorter than my 40 Mhz main clock, and instead always matches the error for my sampling frequency on the logic analyser (either 5ns or 10ns for 200 Mhz). Externally the FPGA is only driving a circuit at a few Mhz, so I am confident with the right amount of study work I can get this working (with help). Thanks for the advice on the Lattice chip, once I have a workable design i'll evaluate if it will fit on something simpler like the Lattice chip or even a Max 10.
  10. Thanks for the advice as always zygot / xc6l45. So, should I be looking for full range signals that are switching at the same point as these little spikes, rather than spikes of the same amplitude? I can see these same little spikes on other nearby signals at the same amplitude at around the same interval. I hadn't noticed they weren't always at that interval, that's a good spot and could be a clue. I can try disabling some of the signals as suggested. I had configured the drive to 4mA on all pins, but after examining the IBIS files for the Artix-7 for LVCMOS33 signal slew rates, I could see the slew rate is quite a bit slower at 8mA than it is at 4mA (about 1 ns slower). I switched the signals to 8mA instead and that has reduced the spikes slightly. Though most of these signals are routing via 74LVC245's to the original chip socket so it probably won't help that much. The slew rate of the original chip is closer to 15 ns, so I made have to add some series resistors in the next version. All outputs are registered following a standard pattern. Every signal is clocked in the circuit via an clock sensitive always block. Then after that, those registers are used to drive an assign statement to one of the output pins. For example: always @(posedge clk33) if (rst) begin muxr <= 40'b1111111100000000000011111111000000000000; end else begin muxr <= {muxr[38:0],muxr[39]}; end assign mux = muxr[39]; Also, the Vivado tool is generating either an OBUF or an IOBUF for every output. I was hoping to get this project to a working, but imperfect state before open sourcing it and then getting help to design a specific board with the FPGA directly on it rather than the CMOD A7. I'm currently reading my way through the rather excellent 'High Speed Digital Design' by Howard W Johnson as recommended by another poster on this forum. It's an excellent book but some of it is going over my head at this stage. I agree with those improvements to the CMOD A7 platform, especially adding LVDS signals.
  11. I've managed to capture the noise that is causing my problem as per the picture below. These spikes are at the exact distance apart of my generated clock (1Mhz). This clock is created by generating a 40Mhz clock in the MMCM, then dividing that clock down by using a shift register. I have the SLEW rate set at SLOW on all pins, and the drive strength set to 4. It looks like my generated clock is generating ringing in the circuit.
  12. Thanks hamster Your's was the only post that I came up with when I googled my problem in the first place. The audio board sure looks like a cool fpga project. I also haven't done any work in matching signals on the top to the bottom, in fact some of my bottom ground plain is not contiguous and relies upon via's so join up the ground plan parts. Not the best idea. Are the series resistors you have added to slow down the slew rates of the fpga outputs?
  13. Yes, they are all set to SLOW which is the default. Thanks
  14. No it doesn't. The original chip is only 40 pins. I am driving those 40 pins via 74lvc245's. Edit: I've tried reducing the drive strength on all the pins (apart from the derived clock) from the default of 12 to 4. It hasn't changed the noise signature or range.
  15. Ok thanks. I've connected wires from the grounds on the PMOD pins to the bottom of the board. It hasn't changed the size of the P-P noise on ground, but it has cleared up the signal a lot. This is a video chip and the VGA output from it is a lot cleaner now than it was before connecting those grounds. This is how I am connecting in the PMOD to by board. It is a simple cable looping from the PMOD back to my board with the outputs used as extra bits for driving the VGA signal I am producing. I will double check I don't have an impedance mismatch by checking the original schematics. Thanks for the suggestion and continued support.