|
|
Joined: Mar 2001
Posts: 17,215 Likes: 234
Very Senior Member
|
Very Senior Member
Joined: Mar 2001
Posts: 17,215 Likes: 234 |
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
Member
|
|
OP
Member
Joined: Jul 2009
Posts: 78 |
And here we have it: The result of the interrupt test program on my real MC-1000:
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
Senior Member
|
|
Senior Member
Joined: Feb 2005
Posts: 449 |
Because my NE555 timer hack keeps the interrupt active for too long.
|
|
|
|
|
Joined: Jul 2009
Posts: 78
Member
|
|
OP
Member
Joined: Jul 2009
Posts: 78 |
(* 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).
|
|
|
|
|
Joined: Jul 2009
Posts: 78
Member
|
|
OP
Member
Joined: Jul 2009
Posts: 78 |
Because my NE555 timer hack keeps the interrupt active for too long. Hm... Looking at the code we see:
static MACHINE_CONFIG_START( mc1000, mc1000_state )
[...]
MDRV_TIMER_ADD_PERIODIC("ne555", ne555_tick, HZ(60))
:
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:
* * * * * *
+------+ +------+ +------+
| | | | | |
+ +------+ +------+ +-...
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?
* * * * * *
+-+ +-+ +-+ +-+ +-+ +-...
| | | | | | | | | | |
+ +----+ +----+ +----+ +----+ +----+
Last edited by Ensjo; 10/19/10 03:20 PM.
|
|
|
|
|
Joined: Feb 2005
Posts: 449
Senior Member
|
|
Senior Member
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
Member
|
|
OP
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...
static MACHINE_CONFIG_START( mc1000, mc1000_state )
[...]
MDRV_TIMER_ADD_PERIODIC("ne555", ne555_tick, HZ(60*10))
and...
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?
|
|
|
|
|
Joined: Feb 2005
Posts: 449
Senior Member
|
|
Senior Member
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
Member
|
|
OP
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?
|
|
|
|
|
Joined: Mar 2001
Posts: 17,215 Likes: 234
Very Senior Member
|
|
Very Senior Member
Joined: Mar 2001
Posts: 17,215 Likes: 234 |
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.
|
|
|
|
2 members (Kale, 1 invisible),
233
guests, and
1
robot. |
|
Key:
Admin,
Global Mod,
Mod
|
|
|
Forums9
Topics9,320
Posts121,923
Members5,074
| |
Most Online1,283
Dec 21st, 2022
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|
