steddyman

Newcomers
  • Content Count

    23
  • Joined

  • Last visited

About steddyman

  • Rank
    Member

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 on
  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 o
  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
  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: https://www.allaboutcircuits.com/textbook/digital/chpt-3/lo
  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 go
  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 t
  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 sampli
  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,
  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 schemat