Controller issue with core development

Discussion of developmental aspects of the MiSTer Project.
nico24
Core Developer
Posts: 93
Joined: Mon May 25, 2020 12:18 am
Has thanked: 43 times
Been thanked: 84 times

Controller issue with core development

Unread post by nico24 »

Hi,

I wonder if anyone has had a similar issue. I've put together a simple arcade core - I'm going to start publishing the step in videos coming up - anyway I'm putting the controller inputs into my core as so (Verilog):

.BUTTONS(~{m_coin, m_start, m_bomb, m_fire, m_right, m_left, m_down, m_up}),

This is the standard setup for the controls as far as I see.

Now if I pull from those controls in that order it works ok. However in my instantiated module, if I change the order like this:

.D({IN0[7:6],in_coin,in_fire,in_right,in_down,in_left,in_up}),

My core doesn't like it and is creating a permanent interrupt on the CPU. Why on earth would the order matter like this?

Has anyone else come across this issue at all?
Thanks.
Flandango
Core Developer
Posts: 459
Joined: Wed May 26, 2021 9:35 pm
Has thanked: 59 times
Been thanked: 383 times

Re: Controller issue with core development

Unread post by Flandango »

Do you have the code posted up anywhere so we can see more details of what is going on?
ExCyber
Posts: 232
Joined: Sun May 24, 2020 3:33 pm
Has thanked: 12 times
Been thanked: 77 times

Re: Controller issue with core development

Unread post by ExCyber »

Yeah, it's a bit tough to reason about without more context. The only scenario I can imagine at the moment that doesn't seem completely off the wall is something along these lines:
  • A CPU that vectors interrupts based on the data bus
  • The inputs are applied to the data bus during the interrupt vector cycle
  • One order of inputs happens to invoke the expected ISR
  • The other order happens to invoke a different ISR that doesn't acknowledge the interrupting device
nico24
Core Developer
Posts: 93
Joined: Mon May 25, 2020 12:18 am
Has thanked: 43 times
Been thanked: 84 times

Re: Controller issue with core development

Unread post by nico24 »

Thanks - I'll setup the code in a github. At the moment I'm just fudging the MiSTer shell to allow the pass-through of the comp sync and RGB signals, so it's only working on my CRT.

The strange thing is that if I change the order of the up and right control inputs it works. I really don't see how that would affect anything.

I can use Signal Tap to monitor the core if I'm using it direct for the USB blaster SOF, but how do I get it working if I'm using the usual RBF with the full MiSTer shell?
paulbnl
Core Developer
Posts: 216
Joined: Sun May 24, 2020 8:48 pm
Has thanked: 49 times
Been thanked: 285 times

Re: Controller issue with core development

Unread post by paulbnl »

nico24 wrote: Thu Nov 25, 2021 5:42 pm I can use Signal Tap to monitor the core if I'm using it direct for the USB blaster SOF, but how do I get it working if I'm using the usual RBF with the full MiSTer shell?
There isn't much of a difference except that you start the rbf/mra on MiSTer instead of clicking the Program Device button. What is the issue that you are having?
nico24
Core Developer
Posts: 93
Joined: Mon May 25, 2020 12:18 am
Has thanked: 43 times
Been thanked: 84 times

Re: Controller issue with core development

Unread post by nico24 »

I'll give it a go. I didn't now you could have it ready for acquisition if you didn't use the Program Device route!
Thanks.
Post Reply