• Content Count

  • Joined

  • Last visited

About FlyMario

  • Rank

Recent Profile Visitors

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

  1. Well, I added a clock and that made a ton of improvement. Now I do have the signals exactly as I wanted them. Thanks a lot guys! FlyMario
  2. Oh, wow I didn't include my timing diagram. What a newbie. So, the first 8 lines are from the C64's keyboard column lines. What happens is (from my theory) the the first 7 lines go low to see if any key is pressed. If it finds a value at all it sequences through all of the column lines accept for the 8th line (A7 Grey). As you can see, all of the lows are easy to pick out accept for last one. That line only goes high if a key is detected... However you can see that it goes low when it is its turn to send out a key. On the very bottom line (pink B7) is from the output of my Spartan 6 FPGA. It is attached to the output trig. I am trying to get that trigger only to go high at the point where line A7 Goes low asking for they key line. What you see instead though is B7 is following A7 too closely. To filter the noise out, I am trying to allow line A6 to tell A7 when we get to it that it can set the trigger high. seems hard to explain. here is a link to how the keyboard is structured. Thanks, Pete
  3. Thank you so very much for your response! My word, I have so much to think about now. Exciting. I am really just having fun, playing with a fpga board and my Commodore 64. Way too old to start this as a new career. I am very thankful folks such as yourself are willing to spread you knowledge. So many new bookmarks to look at now Thanks Again, Pete
  4. There is no clock. I am using the signals from the kbd[7:0] to trigger the logic. Its strange if I am required to use one since it has worked perfectly until this new issue. I am all ears
  5. So, I am starting to get these errors during the Place & Route phase WARNING:Par:288 - The signal kbd<0>_IBUF has no load. PAR will not attempt to route this signal. WARNING:Par:288 - The signal kbd<1>_IBUF has no load. PAR will not attempt to route this signal. WARNING:Par:288 - The signal kbd<2>_IBUF has no load. PAR will not attempt to route this signal. WARNING:Par:288 - The signal kbd<3>_IBUF has no load. PAR will not attempt to route this signal. WARNING:Par:288 - The signal kbd<4>_IBUF has no load. PAR will not attempt to route this signal. WARNING:Par:288 - The signal kbd<5>_IBUF has no load. PAR will not attempt to route this signal. WARNING:Par:288 - The signal kbd<6>_IBUF has no load. PAR will not attempt to route this signal. it only started when I added the enb register. It really makes no sense. `timescale 1ns / 1ps module Trigger(trig,trigb,kbd); output trig; output trigb; input[7:0] kbd; reg trigb; reg trig; reg enb; always begin trigb = kbd[7]; end always @* begin case(kbd) 0: begin enb = 0; trig = 0; end 254: begin // line 0 trig = 0; enb = 0; // kbdphase = 1; end 253: begin // line 1 trig = 0; enb =0; end 251: begin // line 2 trig = 0; enb =0; end 247: begin // line 3 trig = 0; enb =0; end 239: begin // line 4 trig = 0; enb =0; end 223: begin // line 5 trig = 0; enb =0; end 191: begin // line 6 trig = 0; enb = 1; end 127: begin // line 7 if (enb) begin trig = 1; enb = 0; end else begin enb = 0; trig = 0; end end default begin enb = 0; trig = 0; end endcase; end endmodule The idea behind this is that the C64's Keyboard has 8 Column lines that get strobed individually. The row lines will return the keys that are pressed on that column (not implemented). Right now it just throws a line (TRIG) when a line goes high. The problem is that the line 7 does not behave like exactly like the others. It can actually go low for other reasons but never after line 6. So I thought to put up an enable pin to be turned on during line 6 period and then this will let line 7 know it can do its job and it can set the enable register go low again. Anyways, the ISE is giving me a terrible time. Also I can't understand why it requires me to set the enb line low on practically every single part of the case statement... otherwise I get it complaining about a possible latch. Do you all notice anything I am doing wrong? Thanks a lot for any help you can provide.
  6. FlyMario

    FPGA Clock

    Oh wow... thank you very much! This answers the whole point of my long winded question!
  7. FlyMario

    FPGA Clock

    Thanks a lot guys! I will get back to you. I guess I thought that when you have always block, and you are putting in a blocking statement such as A = B; that there must be some clock to check that B had a value to pass and unblock the statement. There are so many contradicting statements on how this works.Blocking statements seem they would cause things to run in Series instead of Parallel. Perhaps I am worrying about this too much. Also, anyone have experience with C64 logic levels think that if I put a 20k resister from ground to the fpga pin and then a 10k resister from the pin to data line would protect the fpga from burning. I use logic level converters but feels like a waste if I could just use a (voltage divider?) resister circuit for the 8 input lines I need. Thanks FlyMario
  8. FlyMario

    FPGA Clock

    I am learning how to program a FPGA (spartan) lately. The language I am using is Verilog which is not really important to this question. I have the FPGA connected to my Commodore 64 via Logic Level Converters. And I am having lot of success. I am reading 8 lines from the Keyboard port looking. My verilog is simply looking for a matching value on those lines. No problems at all. But I am curious, how is the logic managing to work when I have not really set up a clocking line. Is the FPGA using main clock to trigger events to move on in the FPGA. For instance, if you have a blocking statement it would seem that in order to get past that block, there must be some clock checking the incoming value before the logic can continue. Is this true? Or am I missing something. Is there a clock in the fpga that is pushing the logic along? Flymario