vdp corruption

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

By gdx

Prophet (3163)

gdx's picture

27-11-2019, 02:19

I tryed the same program with OUTIs. It works on real MSX1 (TMS9918) and MSX Turbo R in R800 mode, but don't work on MSX2 nor MSX Turbo R in Z80 mode even in 40 columns. (sometimes characters remain the same as the previous, the new value is not taken into account from time to time)

CALSLT	equ	001ch
INITXT	equ	0006Ch
LINL40	equ	0F3AEh
EXPTBL	equ	0FCC1h

	org	100h

	ld	a,40		; 80 for 80 columns
	ld	(LINL40),a

	ld ix,INITXT
	ld iy,(EXPTBL-1)
	call CALSLT
	
	ld	hl,0
	ld	c,099h
	di
	out	(c),l
	ld	a,h
	and	03fh
	or	040h
	out	(c),a
	ei
	ld	b,END-TEXT
	dec	c
	ld	hl,TEXT
BCL:
	outi
	outi
	outi
	outi
	outi
	outi
	jr	nz,BCL
JP4EVER:
	jr	JP4EVER
TEXT:
	db	"abcdefghijklmnopqrstuvwxyz"
	db	"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
	db	"0123456789"
	db	"abcdefghijklmnopqrstuvwxyz"
	db	"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
	db	"0123456789"
	db	"abcdefghijklmnopqrstuvwxyz"
	db	"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
	db	"0123456789"
END:

By DarkSchneider

Paladin (890)

DarkSchneider's picture

27-11-2019, 12:04

Maybe the text mode is slower on V9938, and because TR in R800 mode adds extra wait, there is no problem. Adding the possibility of 80 columns could require extra composition time, locking more time the VRAM for this purpose (rendering).

The OTIR I think should work always. Not sure if applies, but it includes this sentence that could be beneficial to prevent any corruption.

Quote:

Interrupts are recognized and two refresh cycles are executed after each data transfer

Looks like a command specified for any kind of data transfer to devices.

By Grauw

Ascended (8615)

Grauw's picture

27-11-2019, 13:33

DarkSchneider wrote:

Maybe the text mode is slower on V9938

TEXT2 and TEXT1 are both slower on V9938 than TEXT on TMS9918. Quoting:

Quote:

Text mode 1 (aka screen 0, width 40)

As mentioned before, from a VRAM access point of view, Text mode 1 is similar to Text mode 2. Actually from a VRAM access allocation point of view it's identical, only the actually VRAM read addresses are different. This may seem strange because Text mode 1 logically needs a lot less data than Text mode 2. This is because over half of the performed reads are dummy reads:

In Text mode 1 there are still 4 (burst) reads from the name-table, but the 3rd and 4th are dummy reads. In our (limited) measurements the address for read 3 and 4 was the same as for read 2, but with CAS1 active instead of CAS0 (but doesn't really matter as the result is ignored).
There are also 10 dummy reads at the locations that are reserved for reads from the color-table. All these read address 0x1ffff.
And similarly there are 4 reads from the pattern-table, but the 3rd and 4th read address 0x1ffff.

CPU/command-engine access slots

The available CPU/cmd access slots are identical to those in Text mode 2. It's unfortunate there are so many dummy reads in this mode. If this wasn't the case, the available VRAM bandwidth for CPU accesses (or commands on V9958) could have been a lot higher. Especially because the Z80 already cannot access VRAM very fast in this mode. And also because, as we'll see below, on TMS9918 there's no such timing constraint for this mode.

Also you can see visually in the graph that for every access slot on V9938 there are four on TMS9918.

By norakomi

Paladin (1009)

norakomi's picture

27-11-2019, 18:07

The video shows the in game menu
So this happens during that video:

.menuloop:
call PopulateControls ; read out keys and joystick
call checkF1 ;f1 to end menu
call movepointer ;move the pointer
call setmagicgrapx ;set the magic icons
call putmagicinfo ; put the text about the magic skills
call putiteminfo ;put the text about the item
call sethpandmpbars ;put all the hp and mp bars
call removepointerfrommagic ;remove old pointer
call setpointeronmagic ;set new pointer
call setstats ;write text about all the stats
call clearitemslist ;clear the items
call Gosetpointeronitems ;set pointer on items
call setitems ;set all the items
ld hl,waitendcopy | call docopy ;just a small 2x2 copy (just to wait till vdp is not busy anymore)
call switchpage ;now switch page
call setscreenon ;turn on screen
jp .menuloop

By norakomi

Paladin (1009)

norakomi's picture

27-11-2019, 18:08

So basically a lot of copy instructions.
most of them are fast copies, some are slow transparant copies and sometimes I use HMMV fill to clear/fill space.
I use the code docopy to make all the copy instructions.
It takes several frames to finish all these copies.
Then page switches (between page 1 and page 2) and the jp .menuloop starts the whole process again.
no split scren
no switching screen modes
everything simple in screen 5. sprites disabled.

DoCopy:
ld a,32
di
out ($99),a
ld a,17+128
ei
out ($99),a
ld c,$9b
.vdpready:
ld a,2
di
out ($99),a
ld a,15+128
out ($99),a
in a,($99)
rra
ld a,0
out ($99),a
ld a,15+128
ei
out ($99),a
jr c,.vdpready
dw $a3ed,$a3ed,$a3ed,$a3ed
dw $a3ed,$a3ed,$a3ed,$a3ed
dw $a3ed,$a3ed,$a3ed,$a3ed
dw $a3ed,$a3ed,$a3ed
ret

By norakomi

Paladin (1009)

norakomi's picture

27-11-2019, 21:35

machine used for testing:
Turbo R gt

By Grauw

Ascended (8615)

Grauw's picture

27-11-2019, 21:41

So far I see nothing that would cause such behaviour, it all seems pretty normal usage.

Aside from the copies what VDP registers are you accessing? E.g. what does setscreenon do?

By sd_snatcher

Prophet (3135)

sd_snatcher's picture

28-11-2019, 01:06

@norakomi

1) suggestion: try a knockout approach. IOW comment each one of the calls of the menu loop individually, until you find the culprit.

If none of them is individually the culprit, then try to comment the calls without uncommenting the previous one, since it can cause by some unexpected side effect of one routine into another.

2) how's your interrupt handler? Are you using the default IM0+BIOS on frame-0, or any custom RST38h interrupt handler, or IM2?

3) Are you sure that the value of the C register is not being corrupted anywhere before the OUTIs?
(BTW, why not use REPT/ENDR and OUTI instead of a bunch of dw $A3ED?)

4) Please be kind with MA-20 owners Wink

By gdx

Prophet (3163)

gdx's picture

28-11-2019, 01:26

Quote:

DoCopy:
ld a,32
di
out ($99),a
ld a,17+128
ei
out ($99),a
ld c,$9b
.vdpready:
ld a,2
di
out ($99),a
ld a,15+128
out ($99),a
in a,($99)
rra
ld a,0
out ($99),a
ld a,15+128
ei
out ($99),a
jr c,.vdpready
dw $a3ed,$a3ed,$a3ed,$a3ed
dw $a3ed,$a3ed,$a3ed,$a3ed
dw $a3ed,$a3ed,$a3ed,$a3ed
dw $a3ed,$a3ed,$a3ed
ret

RET must be before the data.

By Grauw

Ascended (8615)

Grauw's picture

28-11-2019, 08:27

@gdx The data is OUTI instructions x15 so the ret is fine.

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