Strange issue on real HW

Страница 3/20
1 | 2 | | 4 | 5 | 6 | 7 | 8

By Daemos

Paragon (2044)

Аватар пользователя Daemos

16-04-2015, 09:34

When I look at VDPio.asm I see _vdpsetvramwr:

no ints are disabled during outing to #99. Is this on purpose or is it done prior to the call?

EDIT: I see it is done prior to the call by most of the routines I come by. Chance is small this is the cause of the problems.

EDIT2: I see however that there are some routines that call the _vdpsetvramwr: directly without doing di first.

EDIT3: Also a quick overview of the ISR allthough I am not a 100% sure (have to read quickly) status register 0 is not being set back after lineint. I remember having similar issues on real HW.

	xor	a 			; read S#0
	out (0x99),a
	ld a,128+15
	out (0x99),a

shouldn't this be after you do all your lineint stuff?

By hit9918

Prophet (2927)

Аватар пользователя hit9918

16-04-2015, 18:41

Quote:

It works only at 50 he due to exact timing of some actions
no point in testing at 60hz

instead of "no point in it" I would say it is serving the synchronization bug on a golden plate in a emu config Smile

By hit9918

Prophet (2927)

Аватар пользователя hit9918

16-04-2015, 22:37

@Daemos,
about the status register selection, in p3bios I let the interrupt handler restore the RG15SAV.
then a blitter test goes like this
[code]
waitblt: in a,(0x99) ;I know I set up R15 before and an interrupt wont change this
and xxx
jp nz,waitblt
[code]
no status register setup, removed overhead.

another thing, interrupt handlers that do early EI.
check status register, then check a mutex against being run multiple times, and after that just go EI.
from now on you can code similar to non-interrupt code, e.g. call functions that got a usual DI/EI pair.
an unification in programing model.

The line interrupt is extreme, that can go without the early EI. It doesn't have much code anyways.

But the vblank interrupt tends to be a fatter bar where you call lot more things.
It is a plus to be able to code it more like non-interrupt code.
Also the vblank could get interrupted by "the moonsound on a BPM exactness trip".
Instead being late by a fat vblank handler.

Doing things more like a realtime OS Big smile
But not with ado but coding in common patterns.
The RG15SAV way is nothing new, but the same pattern known from memory mapper mirrors:
ld (mirror),a
out (hardware),a
first the mirror byte, then the hardware.

By ARTRAG

Enlighted (6923)

Аватар пользователя ARTRAG

17-04-2015, 07:35

Daemos wrote:

When I look at VDPio.asm I see _vdpsetvramwr:

no ints are disabled during outing to #99. Is this on purpose or is it done prior to the call?

EDIT: I see it is done prior to the call by most of the routines I come by. Chance is small this is the cause of the problems.

I should always have disabled interrupts always before the call. The idea is that there are cases where I cannot re-enable interrupts between two calls to _vdpsetvramwr.

Daemos wrote:

EDIT2: I see however that there are some routines that call the _vdpsetvramwr: directly without doing di first.

Where ? This could be the problem I cannot spot.

Daemos wrote:

EDIT3: Also a quick overview of the ISR allthough I am not a 100% sure (have to read quickly) status register 0 is not being set back after lineint. I remember having similar issues on real HW.

	xor	a 			; read S#0
	out (0x99),a
	ld a,128+15
	out (0x99),a

shouldn't this be after you do all your lineint stuff?

This latter cannot be the problem, as the ISR code is custom (I have ram in page 0) and all the IN's in my code are after setting register #15.

By ARTRAG

Enlighted (6923)

Аватар пользователя ARTRAG

17-04-2015, 07:47

hit9918 wrote:
Quote:

It works only at 50 he due to exact timing of some actions
no point in testing at 60hz

instead of "no point in it" I would say it is serving the synchronization bug on a golden plate in a emu config Smile

The main loop exceeds the frame time, you get any kind of overflow, and bluemsx is very inaccurate on timings (and more) so you get all a series of problems you will never see on the real thing.
Anyway booting the rom with shift pressed enables 60Hz, so you can try NTSC also on openmsx (an on the real thing). Can you spot the problem there? Bluemsx isn't a valid testbed for this kind of development.

By ARTRAG

Enlighted (6923)

Аватар пользователя ARTRAG

17-04-2015, 08:04

On openmsx I'm trying to test if there are outs while the interrupts are enabled with a debug script by Wouter (thanks!).
On the console command I type:

>debug set_watchpoint write_io 1 "0 255" mytest
>proc mytest {} {
> if {[reg IFF] & 2} {
> message "OUT with EI at PC=[reg PC]"
> }
> }

Sadly I do not get any message in the Status info tab of catapult: not in PAL, neither in NTSC mode (booting with shift).
So, or this debug script has some problems (I've never used debug on command line in openmsx), or the glitch on real HW has to be found elsewhere (!).
Is there someone who has a tested and working debug script for the same purpose on openmsx ?

By Daemos

Paragon (2044)

Аватар пользователя Daemos

17-04-2015, 08:13

Quote:

Where ? This could be the problem I cannot spot.

		xor	a
		ld	(_kBank1),a
		inc	a
		ld	(_kBank2),a
		
		call	_cls
		ld	a, :sprtdata
		ld	(_kBank4),a
		call 	_hw_sprite_init

		ld	a, :_scorebar
		setpage_a
		ld		c,0
		ld		de,256*(mapHeight*16+8)
		call	_vdpsetvramwr
		ld		hl,_scorebar
		ld		bc,0x0098
		ld		a,24
1:		otir
		dec	a
		jr	nz,1b

in main.asm at start

By ARTRAG

Enlighted (6923)

Аватар пользователя ARTRAG

17-04-2015, 08:46

Smile thanks but this cannot be the issue.

This code cannot be interrupted as few lines above I did

		call	setrampage0
		ld		a,0xc9
		ld		(0x38),a

so no interrupt ;-)
After all you see the screen being built and the score bar being loaded in VRAM also on real HW, so this part works at least till line 201 (included).

The problems have to be after line 210 where I do

		call	_isrinit

and the main loop starts.

By Daemos

Paragon (2044)

Аватар пользователя Daemos

17-04-2015, 08:55

If disabling _isrinit will the engine at least run?

What else of your code is located in page 0?

By Grauw

Ascended (10699)

Аватар пользователя Grauw

17-04-2015, 13:13

	ei
	halt 

Does this work when interrupts are disabled? Enabling interrupt has a 1-instruction delay after all, so they will only be enabled after the halt? Either way, probably not the cause of your problems. Btw, also, no need to disable interrupts at the start of your ISR afaik (the Z80 disables them automatically).

Страница 3/20
1 | 2 | | 4 | 5 | 6 | 7 | 8