Stack overflow while using H.KEYI hook

Page 3/4
1 | 2 | | 4

By Grauw

Ascended (10074)

Grauw's picture

03-09-2020, 20:10

tvalenca wrote:

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?

By tvalenca

Paladin (747)

tvalenca's picture

03-09-2020, 20:45

ducasp wrote:

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.

By tvalenca

Paladin (747)

tvalenca's picture

03-09-2020, 20:47

Grauw wrote:

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 START

Actually, I've used DI/EI during hook install.

By Grauw

Ascended (10074)

Grauw's picture

03-09-2020, 21:11

tvalenca wrote:
Grauw wrote:

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.

tvalenca wrote:
    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.

By tvalenca

Paladin (747)

tvalenca's picture

03-09-2020, 21:27

Grauw wrote:
tvalenca wrote:
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.

Grauw wrote:
tvalenca wrote:
    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.

By Grauw

Ascended (10074)

Grauw's picture

03-09-2020, 21:47

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…

By tvalenca

Paladin (747)

tvalenca's picture

03-09-2020, 22:27

Grauw wrote:

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_HOOK

instead this?

ROUTINE:
    in a,(#66)
    bit 1,a
    jr z,SPLIT
    bit 0,a
    jr z,REFRESH
    jp OLD_HOOK

Right now I don't have any clues, so anything seems plausible.

By pgimeno

Champion (300)

pgimeno's picture

03-09-2020, 22:41

tvalenca wrote:

EDIT #2: can I do this:

ROUTINE:
    in a,(#66)
    rra
    jr c,REFRESH
    rra
    jr c,SPLIT
    jp OLD_HOOK

instead 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.

By tvalenca

Paladin (747)

tvalenca's picture

03-09-2020, 22:59

pgimeno wrote:

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.

pgimeno wrote:

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)

By tvalenca

Paladin (747)

tvalenca's picture

03-09-2020, 23:14

tvalenca wrote:

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.

Page 3/4
1 | 2 | | 4