Interrupts and gfx9000

Page 3/5
1 | 2 | | 4 | 5

By assembler

Champion (378)

assembler's picture

01-08-2012, 15:22

Sorry, I forgot to mention it.

Yes GuyveR800 helped me about the interruption issue and other points, i.e. screensplit.

Thanks again!

By MsxKun

Paladin (920)

MsxKun's picture

08-10-2019, 00:32

Hi

Sorry to resurrect this, but I've been having fun messing with P1 mode on the GFX9000 and all went fine until I got into interrupts.
First, I always get a value of 3 at interrupt flags even if I only enable IEV (or IEH) interrupt.
Second, If I want to make a split, I enable both interrupts. But it crashes, unless I put the interrupt line under 212 or so.
Third. I can't copy a single byte inside the interrupt routine to VRAM. I get screen junk. The same copies to VRAM works ok outside the interrupt routine.

Notes: VDP Ints are disabled. I use HTIMI hook, so I depend on BIOS. I started with a setup fairly similar to what assembler is using, but tried to do exactly the same and also fails.

I found another dirty way to do the split anyway, but still can't copy a single byte to VRAM inside my interrupt.

By assembler

Champion (378)

assembler's picture

08-10-2019, 09:47

Do you clean the Interrupt Flag Port when you enter in the interruption?

-By writing "1", the related bit flag is reset.

Until the bit is reset, the interruption is fired permanently

By Manel46

Champion (431)

Manel46's picture

08-10-2019, 10:34

Perhaps it is necessary to mention that you have to write the line number that produces the change in R # 10

By MsxKun

Paladin (920)

MsxKun's picture

08-10-2019, 10:36

assembler wrote:

Do you clean the Interrupt Flag Port when you enter in the interruption?

-By writing "1", the related bit flag is reset.

Until the bit is reset, the interruption is fired permanently

hi, yes. As i said, I was doing almost the same as you, and later I tried exactly the same.
At the end I read the value and write the same value so all the flags triggered should be reset.

By MsxKun

Paladin (920)

MsxKun's picture

08-10-2019, 10:36

Manel46 wrote:

Perhaps it is necessary to mention that you have to write the line number that produces the change in R # 10

I do.

By PingPong

Prophet (3448)

PingPong's picture

08-10-2019, 16:28

hi, of course i guess running in a emulator (openMSX) all works fine, right?

By MsxKun

Paladin (920)

MsxKun's picture

08-10-2019, 19:40

MsxKun wrote:
Manel46 wrote:

Perhaps it is necessary to mention that you have to write the line number that produces the change in R # 10

I do.

And related to that, as it also depends on R#11, if i keep R#11 at cero, it ignores the line. No matter where i set it. But, if I put R#11 to 1, then it works. Not sure that's the normal behaviour...

By MsxKun

Paladin (920)

MsxKun's picture

08-10-2019, 19:43

PingPong wrote:

hi, of course i guess running in a emulator (openMSX) all works fine, right?

Nope.
I'm doing the tests on openMSX. So I would suspect of that, but then, assembler demo works perfectly on the same setting. And i checked the code on the debugger (before asking here anything) to be sure it does the same I was doing.
The only difference I found was that he used DOS and I'm with a ROM. So I have BIOS on, but shouldn't matter....

I don't have a GFX9000 yet.... only doing some tests. I hope to fix that some day Tongue

By Manel46

Champion (431)

Manel46's picture

08-10-2019, 20:38

MsxKun wrote:

And related to that, as it also depends on R#11, if i keep R#11 at cero, it ignores the line. No matter where i set it. But, if I put R#11 to 1, then it works. Not sure that's the normal behaviour...

In R # 11, bits 0 and 1, are to complete the number of lines, in cases of "Y", greater than 256. If you write something, it exceeds the normal height.
Bit 7 to 1 (IEHM), generates interruption in all lines.

Page 3/5
1 | 2 | | 4 | 5