[SOLVED] Problem with delay routine with T1 timer of 6522

[claw]

Hello,

I was trying delay routine using timer T1 of 6522.
In the code, basically, I have first configured LCM in 4bit mode and then after that setup the timer and toggle LED with the timer value.
Clock is 1MHz and timer value I have set is for 50ms (~50000)
I am checking for a count of 10 which should give 500ms. But the LED is always ON. It does not blink.
I removed my logic and took Ben's logic from his video and still the same.

One doubt I have is whether the interrupt is firing or not.
The only change I have made is I am using a 8-bit counter value (in ram) instead of 16/32 bit used by Ben in the videos.

Attached : Code.

PS : I did not continue this post in the previous thread as I felt that this is a new problem. Please merge it if you find that a new thread is not needed.

Thanks

[BigEd]

If you have doubt about whether an interrupt is firing, just add some code to your ISR and check the effect. For example, store FF to some location, and then later inspect it with your monitor.

(I am assuming you have some kind of machine monitor... perhaps you don't. That's something you need!)

Perhaps first of all check your code in user context: you need to know that you can turn your LED on, turn it off, and toggle it. Check you know how to do that, before getting interrupts involved.

[claw]

Hi
Toggling LED is already working fine with crude loop based delay.
But using timers it is not working. Tomorrow I plan to single step and debug using arduino.

Thanks

[gfoot]

The code looks OK to me.

You could try disabling the interrupts for now and polling the 6522 for the interrupt flag instead, it's fairly easy to do - just disable the interrupt flag rather than enabling it:

Code: Select all

  lda #%01000000  ; Disable timer 1 interrupt
  sta IER

and then in your loop, while waiting for the count to reach 10, also check whether the interrupt is due and manually do what would have been done in the ISR:

Code: Select all

loop:
  lda #%01000000
  bit IFR
  beq nointerrupt
  bit T1CL ; Clear interrupt flag
  inc COUNT
nointerrupt:
  ... rest of loop as before

All I did was paste the guts of your ISR into the loop, and made it skip over it if the T1 interrupt flag is not set yet. So this code uses the 6522 in exactly the same way as your existing code, it's just the CPU side is driven by polling rather than a hardware interrupt. If this works, then it looks like there is an issue with your interrupts in the hardware (as we've kind of already discussed in the other thread)

[claw]

gfoot wrote:

If this works, then it looks like there is an issue with your interrupts in the hardware (as we've kind of already discussed in the other thread)

Thanks, I will try what you have suggested. But which "other thread" are you quoting here? can you please give a link?

[gfoot]

claw wrote:

Thanks, I will try what you have suggested. But which "other thread" are you quoting here? can you please give a link?

Oh I'm sorry, I mixed you up with another user, my mistake!

[claw]

gfoot wrote:

claw wrote:

Thanks, I will try what you have suggested. But which "other thread" are you quoting here? can you please give a link?

Oh I'm sorry, I mixed you up with another user, my mistake!

No problem.
I tried your solution. But it does not work.
The LED stays LIT (in both cases - with int and with your solution).

I will try to debug the connections and if everything does not work, I will try single stepping to find the problem.

[claw]

Thanks for your suggestions guys.

Apparently, I had a connection problem

Address line A13 of RAM chip was not connected to the bus.
Stack was working fine with this setup. But I guess the variables at address starting from 0x00 was not working fine.

I have a 32KB RAM chip by only 8KB ROM chip. So, I have not completely connected the address bus for the ROM and this was partially reflected in the RAM!

Thanks again.

[BigEd]

A good result - thanks for closing the loop!

I believe it's true, and important, that building computers at this level is not much like Lego: sometimes you will need to investigate and check things. In fact it's good to do that, because you learn more. But, of course, introductory material like Ben's videos will tend to show everything proceeding fine.

[pjdennis]

BigEd wrote:

A good result - thanks for closing the loop!

I believe it's true, and important, that building computers at this level is not much like Lego: sometimes you will need to investigate and check things. In fact it's good to do that, because you learn more. But, of course, introductory material like Ben's videos will tend to show everything proceeding fine.

In fairness to Ben Eater his videos do regularly include "mistakes" and subsequent troubleshooting, which sets the stage that things will not always be smooth sailing and plants ideas on how to go about investigating problems. I write "mistakes" in quotes as I'm not sure if they are always genuine vs. things he thinks a beginner might run in to by accident. Relatedly, I do like the approach of adding functionality in small increments and testing as you go - I think this is especially helpful while learning something new.

[BigEd]

That's good to hear!

[claw]

I think the problem I faced has nothing to do with Ben's videos. Because, I had a 8K rom instead of 32K ROM which Ben used. So, I had a couple of NC pins in the ROM. By mistake, I mirrored those connections to the RAM (Which is by the way 32K)