but instead resuming, the code is still loosing itself and pushing anything on stack, corrupting RAM in the process.
Did you remove the di / ei already?
You are focusing on the wrong stuff... It doesn't matter if you have a C7 after CD xx yy, what matters is if you DO NOT HAVE a C9 (ret) after your CD xx yy... Because if you don't, once your HKEY_I routine returns, it will execute whatever is in front of CD xx yy, and thus, there is a good chance that it will execute some strange code.
(...)
Sorry if I didn't make myself clear: this change is scheduled for the next time I sit down to work on it.
EDIT: I actually made that change on last build. See my code on next post.
Did you remove the di / ei already?
Yep. Here's the last code:
H.TIMI equ #FD9A
START:
org #C000
di
ld a,10
out (#64),a
ld a,32
out (#63),a
ld a,11
out (#64),a
ld a,0
out (#63),a
ld a,9
out (#64),a
ld a,2
out (#63),a
ld hl,H.TIMI
ld de,OLD_HOOK
ld bc,5
ldir
ld hl,H.TIMI
ld de,ROUTINE
ld (hl),#cd
ld (H.TIMI+1),de
ei
ret
ROUTINE:
in a,(#66)
bit 1,a
jr z,SPLIT
bit 0,a
jr z,REFRESH
jp OLD_HOOK
SPLIT:
ld a,2
out (#66),a
ld a,13
out (#64),a
ld a,4
out (#63),a
jp OLD_HOOK
REFRESH:
ld a,1
out (#66),a
ld a,13
out (#64),a
ld a,0
out (#63),a
jp OLD_HOOK
OLD_HOOK:
db #C9,#C9,#C9,#C9,#C9
end STARTActually, I've used DI/EI during hook install.
Did you remove the di / ei already?
Yep. Here's the last code:
H.TIMI equ #FD9A
You must hook H.KEYI (FD9AH), which is called on every interrupt.
H.TIMI is specific for the internal V9938 VDP vertical blanking interrupt and called only then.
ld hl,H.TIMI
ld de,ROUTINE
ld (hl),#cd
Either change this to C3H (jp), or write C9H (ret) to H.KEYI + 3. The former is a bit faster.
H.TIMI equ #FD9A
You must hook H.KEYI (FD9AH), which is called on every interrupt.
H.TIMI is specific for the internal V9938 VDP vertical blanking interrupt and called only then.
Wrong label name, right hook address. Fixed.
ld hl,H.TIMI
ld de,ROUTINE
ld (hl),#cd
Either change this to C3H (jp), or write C9H to H.KEYI + 3. The former is a bit faster.
Done (changed to #C3). Same results.
EDIT:
Disabled Video9000 extension on openMSX and it stopped hanging. Either I messed the ISR code or V9990 code.
Does the interrupt get reset properly? I’m not too familiar with V9990 so I can’t tell for sure by just reading the code. However after the out (#66),a (that’s the flag reset, right?) you could add an in a,(#66) and a debugger breakpoint to verify whether the flag was indeed reset…
Does the interrupt get reset properly? I’m not too familiar with V9990 so I can’t tell for sure by just reading the code. However after the out (#66),a (that’s the flag reset, right?) you could add an in a,(#66) and a debugger breakpoint to verify whether the flag was indeed reset…
ISR main "ROUTINE:" gets executed, but it never detects a V9990 interrupt. ("SPLIT:" and "REFRESH:" addresses execution never executes)
Port #66 is Interrupt flag port, where (as stated on V9990 manual) bit 1 is set means "display position flag" and bit 0 set means "Vertical display period completion flag". (FYI, bit 2 means "Command completion flag" and the rest have no meaning) And writting 1 to them means flag reset.
What bugs me is: When there is no V9990 hooked to the system, code does nothing and system does not hang. The moment I plug a V9990, code still does nothing but SP wraps around, memory gets corrupted, and eventually emulation reaches a DI;HALT.
EDIT: Not a machine/version related issue either: Tried Panasonic FS-A1GT, FS-A1WX, FS-A1F, and Gradiente Expert DD Plus (why? those are the machines I once owned and -more importantly- all of those contains a disk drive)
EDIT #2: can I do this:
ROUTINE:
in a,(#66)
rra
jr c,REFRESH
rra
jr c,SPLIT
jp OLD_HOOKinstead this?
ROUTINE:
in a,(#66)
bit 1,a
jr z,SPLIT
bit 0,a
jr z,REFRESH
jp OLD_HOOKRight now I don't have any clues, so anything seems plausible.
EDIT #2: can I do this:
ROUTINE:
in a,(#66)
rra
jr c,REFRESH
rra
jr c,SPLIT
jp OLD_HOOKinstead this?
ROUTINE:
in a,(#66)
bit 1,a
jr z,SPLIT
bit 0,a
jr z,REFRESH
jp OLD_HOOK
These are not equivalent. rra will set carry if the bit is set, therefore jr c,... will jump if the bit is set. On the other hand, bit 0,a // jr z,... will jump if the bit is clear instead of set. Furthermore, if both bits can be active at the same time, that changes which one is given priority.
These are not equivalent. rra will set carry if the bit is set, therefore jr c,... will jump if the bit is set. On the other hand, bit 0,a // jr z,... will jump if the bit is clear instead of set.
I could use jr nc instead. but thanks for pointing this.
Furthermore, if both bits can be active at the same time, that changes which one is given priority.
that won't happen, unless I set line interrupt to last screen line.
But I made the math, rra takes 4(5) cycles to execute and bit takes just 8(10) (i thought it was slower)
EDIT: Not a machine/version related issue either: Tried Panasonic FS-A1GT, FS-A1WX, FS-A1F, and Gradiente Expert DD Plus (why? those are the machines I once owned and -more importantly- all of those contains a disk drive)
EDIT #3: (could not actually edit my post)
This is not (apparently) an emulation issue. Got same results on WebMSX.