Previous Thread
Next Thread
Print Thread
Page 9 of 14 1 2 7 8 9 10 11 13 14
Joined: Mar 2001
Posts: 16,892
Likes: 51
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,892
Likes: 51
Either there's a missing ack for that interrupt (a hardware register the interrupt handler writes to lower the interrupt) or it's supposed to be edge-triggered rather than level-triggered.

Joined: Jul 2009
Posts: 78
Ensjo Offline OP
Member
OP Offline
Member
Joined: Jul 2009
Posts: 78
And here we have it: The result of the interrupt test program on my real MC-1000:
Code:
CALL 16128
......1......1...............1..
1..1......1...............1.....
.....1................1......1..
2......1......1...............1.
1......1......1......1......1...
.......1......1...............1.
2......1...............1.......1
..........1.....1......1......1.
.1.....1......1.......1.....1...
2...
OK
CALL 16128
...............1.....1.....1....
1........1.....1.....1.....1....
1.......1..............1....1...
2.1.....1.....1.....1......1....
1...............1...............
2......1.....1.............1....
2.........1.....1.....1.....1...
1........1.....1.....1.....1....
1.......1......1.....1.....1....
1.......
OK

It's a little more erratic than I expected*, but there are the predicted 1's.

(* Why do 2's appear sometimes, and also consecutive interrupts too close to each other?)

Joined: Feb 2005
Posts: 449
C
Senior Member
Offline
Senior Member
C
Joined: Feb 2005
Posts: 449
Because my NE555 timer hack keeps the interrupt active for too long.

Joined: Jul 2009
Posts: 78
Ensjo Offline OP
Member
OP Offline
Member
Joined: Jul 2009
Posts: 78
Originally Posted By Ensjo
(* Why do 2's appear sometimes, and also consecutive interrupts too close to each other?)

Just for the record, I think I undestood the pattern:
  • The normal behaviour is that the interrupt occurs after every 6 or 5 dots are printed.
  • The long sequences of dots are probably caused by interrupts being disabled somewhere down the ROM printing routine I call; interrupts that occur right in that moment are lost.
  • The 2's and the short sequences of dots appear at the end and at the beginning of the lines. That apparent "agglutination" of interrupts occur because extra processing is needed to SCROLL the screen (copying the contents of the VRAM 32 bytes up, filling the last line with spaces).

Curt Coder #65163 10/19/10 12:52 PM
Joined: Jul 2009
Posts: 78
Ensjo Offline OP
Member
OP Offline
Member
Joined: Jul 2009
Posts: 78
Originally Posted By Curt Coder
Because my NE555 timer hack keeps the interrupt active for too long.

Hm... Looking at the code we see:
Code:
static MACHINE_CONFIG_START( mc1000, mc1000_state )
[...]
    MDRV_TIMER_ADD_PERIODIC("ne555", ne555_tick, HZ(60))

and:
Code:
static TIMER_DEVICE_CALLBACK( ne555_tick )
{
    mc1000_state *state = timer.machine->driver_data<mc1000_state>();

    if (state->ne555_int == ASSERT_LINE)
    {
        state->ne555_int = CLEAR_LINE;
    }
    else
    {
        state->ne555_int = ASSERT_LINE;
    }

    cputag_set_input_line(timer.machine, Z80_TAG, INPUT_LINE_IRQ0, state->ne555_int);
}

If I understand this, "ne555_int" remain alternately "asserted" and "clear" (1 and 0, up and down, whatever) for 1/60 second:
Code:
*      *      *      *      *      *
+------+      +------+      +------+
|      |      |      |      |      |
+      +------+      +------+      +-...

How should this work instead? At every 1/60 second it should have a quick "asserted" time, and then remain "clear" for the rest of the cycle?
Code:
*      *      *      *      *      *
+-+    +-+    +-+    +-+    +-+    +-...
| |    | |    | |    | |    | |    |
+ +----+ +----+ +----+ +----+ +----+

Last edited by Ensjo; 10/19/10 03:20 PM.
Ensjo #65164 10/19/10 01:19 PM
Joined: Feb 2005
Posts: 449
C
Senior Member
Offline
Senior Member
C
Joined: Feb 2005
Posts: 449
It's connected as an astable oscillator in the MC-1000. It should work as you described above (short 0, long 1)

http://www.kpsec.freeuk.com/555timer.htm#astable

Joined: Jul 2009
Posts: 78
Ensjo Offline OP
Member
OP Offline
Member
Joined: Jul 2009
Posts: 78
Hm... Maybe this could be done by increasing the frequency and adding a counter somewhere? Let's suppose it should remain "clear" (is "clear" = 0?) during 1/10 of the cycle. We could have something like...
Code:
static MACHINE_CONFIG_START( mc1000, mc1000_state )
[...]
    MDRV_TIMER_ADD_PERIODIC("ne555", ne555_tick, HZ(60*10))

and...
Code:
static TIMER_DEVICE_CALLBACK( ne555_tick )
{
    mc1000_state *state = timer.machine->driver_data<mc1000_state>();

    if (++counter == 10)
    {
        counter = 0;
        state->ne555_int = CLEAR_LINE;
    }
    else
    {
        state->ne555_int = ASSERT_LINE;
    }

    cputag_set_input_line(timer.machine, Z80_TAG, INPUT_LINE_IRQ0, state->ne555_int);
}

Whaddya think?

Ensjo #65170 10/19/10 01:58 PM
Joined: Feb 2005
Posts: 449
C
Senior Member
Offline
Senior Member
C
Joined: Feb 2005
Posts: 449
Non-hacky solution would be to either emulate an NE555 chip properly, or have 2 scanline timers (one for ASSERT, another for CLEAR_LINE).

Joined: Jul 2009
Posts: 78
Ensjo Offline OP
Member
OP Offline
Member
Joined: Jul 2009
Posts: 78
Aha. Well, proper emulation of NE555 may take a while... Is the 2-timers solution quickly implementable? How to displace the second timer wave from the first, so that they are not coincident?

Ensjo #65175 10/19/10 03:08 PM
Joined: Mar 2001
Posts: 16,892
Likes: 51
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,892
Likes: 51
For the two-timers solution you'd start the second timer in the service routine for the first one. It's a fairly common pattern in MAME/MESS.

Page 9 of 14 1 2 7 8 9 10 11 13 14

Link Copied to Clipboard
Who's Online Now
1 members (1 invisible), 21 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,069
Posts118,925
Members5,014
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com