Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sinclair/sprinter.cpp: update #12269

Merged
merged 3 commits into from
Apr 19, 2024
Merged

sinclair/sprinter.cpp: update #12269

merged 3 commits into from
Apr 19, 2024

Conversation

holub
Copy link
Contributor

@holub holub commented Apr 17, 2024

  • accelerator writes through page fd only in COPY mode
  • io access 1f (z84 int) available through replacing to 0f
  • hold IRQ for 32 clocks (unscaled)

- accelerator writes through page fd only in COPY mode
- io access 1f (z84) available through replacing to 0f
- hold IRQ for 32 clocks (unscaled)
Comment on lines 1522 to 1530
TIMER_CALLBACK_MEMBER(sprinter_state::irq_on)
{
m_maincpu->pulse_input_line(INPUT_LINE_IRQ0, attotime::from_ticks(26, m_maincpu->clock()));
if (!m_hold_irq)
{
m_maincpu->set_input_line(INPUT_LINE_IRQ0, ASSERT_LINE);
m_irq_off_timer->adjust(attotime::from_ticks(32, m_maincpu->unscaled_clock()));
}
update_int(false);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this interrupt continue to be held for the full 32 cycles even if there’s an interrupt acknowledge cycle, or should an interrupt acknowledge cycle clear this interrupt as well as the other one? (The implementation currently does the latter – clears both kinds of interrupt on an interrupt acknowledge cycle.)

Comment on lines 1532 to 1536
TIMER_CALLBACK_MEMBER(sprinter_state::irq_off)
{
m_hold_irq = 0;
m_maincpu->set_input_line(INPUT_LINE_IRQ0, CLEAR_LINE);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be called two ways now – from m_irq_off_timer expiring, and from an interrupt acknowledge cycle on the main CPU. If it’s called from an interrupt acknowledge cycle, should it cancel the timer? If it doesn’t, this sequence of events can happen:

  • irq_on asserts interrupt and starts m_irq_off_timer
  • Interrupt acknowledge cycle causes irq_off to be called, clearing interrupt
  • m_irq_off_timer fires, causing irq_off to be called again

It’s probably harmless given what it’s doing, but it will go through another timer update and then go through the scheduler again to clear the IRQ line.

@holub holub marked this pull request as draft April 19, 2024 17:27
@holub
Copy link
Contributor Author

holub commented Apr 19, 2024

Please hold on merging this. I need to double check this IRQ behaviour

@holub holub marked this pull request as ready for review April 19, 2024 18:20
@holub
Copy link
Contributor Author

holub commented Apr 19, 2024

False alarm. It's good to go.

@cuavas cuavas merged commit d87085e into mamedev:master Apr 19, 2024
2 of 5 checks passed
@holub holub deleted the sp2k branch June 30, 2024 13:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants