screen 8 smooth horizontal scrolling

Page 3/4
1 | 2 | | 4

By ARTRAG

Enlighted (6710)

ARTRAG's picture

21-02-2011, 23:14

Under dos2 the files cannot stay in subdirectories or the CPM libraries will fail finding the data

By ARTRAG

Enlighted (6710)

ARTRAG's picture

22-02-2011, 00:15

screen8_2011_02_22.rar presents less glitches on real HW (tested on my TR GT)
It seems that moving R#18 while VDP commands are in execution can cause problems to the command
It seems also that it has to do with the fact that the VDP is in the horizontal retrace when R#18 is canged....
weird... investigating on this oddness of the vdp
The files work on msxdos 1 (being based on cpm libraries)
Under msxdos2 all files have to be in the root: nevertheless, sometimes small sections of the image get lost
investigating also on this oddness of the C libraries

https://sites.google.com/site/testmsx/screen-8-smooth-horizontal-scrolling

By sd_snatcher

Prophet (3498)

sd_snatcher's picture

22-02-2011, 03:55

@ARTRAG

There are a lot of oddities regarding the R#18. MSX MAP already lists some of them:

http://map.grauw.nl/articles/vdp_guide.php

If you find any new one, please contribute to the article. :)

By PingPong

Prophet (3841)

PingPong's picture

22-02-2011, 21:16


It seems that moving R#18 while VDP commands are in execution can cause problems to the command
It seems also that it has to do with the fact that the VDP is in the horizontal retrace when R#18 is canged....

time ago i've asked myself if changing r18 during active area (non border area) can cause data corruption when a command is in progress. I suspect no.
If my guess is true, maybe one could change r18 a little after the vdp reached the active area.

By ARTRAG

Enlighted (6710)

ARTRAG's picture

22-02-2011, 22:41

New version! I fixed the blue issue in the palette of screen 8
Now colors look closer to the original

In version 2 of screen8_2011_02_22.rar I've tried to enable sprites before moving r#18

At TNI MAP
http://map.grauw.nl/articles/vdp_guide.php
it says:
Q: r#18 in combination with VDP commands corrupts VRAM?

A: Yes. This issue only occurs when you have the sprites (or screen) disabled. If you use the screen position adjust register while executing a copy command and with sprites disabled, it will corrupt the byte the VDP command is currently processing. So, if that is the case, you should wait with setting r#18 until the VDP’s CE bit indicates the current command is finished.

The current code makes sure sprites are enabled before moving r#18 but still few dots appear in the copies....
Actually this does not seem to fix the glitces....

the critical code is in main.c and is

vblank:
	ld	a,(RG8SAV)		; enable sprites
	out	(0x99),a
	ld	a,8+128
	out	(0x99),a

	ld	a,(_displaypage)
	add a,a ;x32
	add a,a
	add a,a
	add a,a
	add a,a
	add a,31
	out (0x99),a
	ld a,2+128
	out (0x99),a
	
	ld	a,(_xoffset)
	add	a,-8
	and	0Fh
	out	(099h),a
	ld	a,18+128
	out	(099h),a
....

and also

lint:					
	xor	a
	out	(099h),a
	ld	a,18+128
	out	(099h),a		; setadjust 0,0
	
	ld a,31
	out (0x99),a
	ld a,2+128
	out (0x99),a		; scorebar in page 0

	ld	a,(RG8SAV)
	or	2				; disable sprites
	out	(0x99),a
	ld	a,8+128
	out	(0x99),a
....

Where lint is called at line 144 when sprites are active: sprites are disactivared AFTER R#18 is set

vblank is called at line 192: here we wait some cycles after re-enabling sprites before setting R#18

Any suggestion?
https://sites.google.com/site/testmsx/screen-8-smooth-horizontal-scrolling/screen8_2011_02_22.rar?attredirects=0&d=1

By monant

Resident (48)

monant's picture

22-02-2011, 23:58

hallo ARTRAG ,
does set adjust (0,0) always happen in the same point on screen or there may be a delay dependent on some condition ( JP C,.... / JP Z,.. ) ?
have you tried putting some NOPs before set adjust (0,0) in order to be out of some critical regions ?
( during horizontal retrace it takes about 16microsec right border - right erase time -sync signal -left erase time - left border )Smile

By NYYRIKKI

Enlighted (5900)

NYYRIKKI's picture

23-02-2011, 07:28

Under dos2 the files cannot stay in subdirectories or the CPM libraries will fail finding the data

Bullshit warning!

(Or at least good explanation needed. I don't know how this could happen.)

By ARTRAG

Enlighted (6710)

ARTRAG's picture

23-02-2011, 08:15

I have no idea on why the C I/O does not fully work under msxdos2
It is based on CPM libraries (no commercial crosscompiler have ever supported msx)
I had to provide a byte move routine to move chunks of bytes in ram (it was to be provided by the user in case of system with DMA)
If you want to solve the riddle, sources are included: I can pass you also the development environment (Hitech C v7.8p2)

By ARTRAG

Enlighted (6710)

ARTRAG's picture

23-02-2011, 08:22

hallo ARTRAG ,
does set adjust (0,0) always happen in the same point on screen or there may be a delay dependent on some condition ( JP C,.... / JP Z,.. ) ?
have you tried putting some NOPs before set adjust (0,0) in order to be out of some critical regions ?
( during horizontal retrace it takes about 16microsec right border - right erase time -sync signal -left erase time - left border )Smile

Both routines are called by a very simple interrupt handler that tries to discriminate between the two sources of interrupt:

	
_scroll:
	push	af
	
	xor	a 			; read S#0
	out (0x99),a
	ld a,128+15
	out (0x99),a
	in	a,(0x99)
	rlca
	jp	c,vblank
	
	ld a,1 			; read S#1
	out (0x99),a
	ld a,128+15
	out (0x99),a
	in a,(0x99)
	rra
	jp	c,lint	
	
	pop	af
	ret				; ?? what the hell I'm doing here ??

Actually Vblank interrupt could be delayed by the execution of some large loops under DI/EI that I need in lint for sending VDP commands

So lint sends VDP commands, vblank can interrupt it whne the former enables interrupts

In the current code nothing delayes liint as the main is always with EI enabled

By monant

Resident (48)

monant's picture

23-02-2011, 22:38

ARTRAG so setadjust (0,0) occurs almost always in the same spot .
Just to rule out my hypothesis , would you add a variable delay loop ( trying different values between 0 and 20 microsec) before setadjust (0,0) ?

the VDP manual doesn't help us too much in this case
we know the reg18 vertical position Y is read each frame , and the reg18 horizontal position X is read each scanline , but we dont know when we cannot
manipulate it safely

I think that for developers it would be a good thing to have a REFERENCE Software, to be run on real MSX hardware , which tests some particular VDP register and their behavior allowing different users to compare their results.
Such a program similar to the one at TNI MAP site which tests VDP COPY COMMANDS speed

Smile

Page 3/4
1 | 2 | | 4