Strange issue on real HW

Page 19/20
12 | 13 | 14 | 15 | 16 | 17 | 18 | | 20

By ARTRAG

Enlighted (6236)

ARTRAG's picture

28-05-2015, 23:28

https://youtu.be/Za9tPEgOAgk
New enemies (still one SPT)
Shadows for barriers
Bullets can hit barriers

By mtn

Master (248)

mtn's picture

29-05-2015, 01:30

Now I can compile it from git and test it again Smile

By ARTRAG

Enlighted (6236)

ARTRAG's picture

29-05-2015, 06:28

There is also the rom among the sources

By ARTRAG

Enlighted (6236)

ARTRAG's picture

13-06-2019, 23:29

I did a small test code with comments to show how horizontal scrolling works.
https://github.com/Maneldemo/Uridium-2-for-msx/blob/master/H...
The explanation is here:

;----------------------------------------------------------------------------
; Horizontal scrolling in Graphic 7 mode on msx2
; by artrag
;
; Abstract: Horizontal scrolling on msx 2 is a sort of holy grail.
; Here follows an overview on the approach followed in Uridium 2 beta 
; and a simplified version of its scrolling engine in Graphic 7 mode.   
; We focus on side scrolling right to left, the extension to the other 
; direction is direct.
; The image to scroll is composed by tiles 16x16 pixels, the screen 
; window is 240x160 (taller windows are possible only in PAL mode). 
;
; Memory layout
;
; As we are in Graphic 7 mode, we have only two VRAM pages that have to be
; used to show the screen window using  double buffering (i.e. we plot on one page 
; while we show the other page).
; This implies that the tiles have to stay in RAM or ROM. 
; Moreover, as we will see later, the access to the tiles will be demanded to the z80,
; leaving to the vdp the task of moving the screen. 
;
; The engine relies on a mega rom mapper with 8K pages (here Konami SCC) as a  
; full tile set of 256 tiles of 16x16 pixels takes 64KB of space.
; Naturally using a ram mapper or less tiles, other solutions are possible.
; Each tile is stored column-wise (i.e. successive bytes belong to the same column), 
; this in order to simplify the task of the z80 which is in charge of plotting the 
; new columns of pixels that enter the screen.
; 
; The map is stored in RAM row-wise and, to simplify line changes, as map size is 256x10 
; Each byte in the map is a tile number.
; As a tile is 16x16=256 bytes, a page in the rom mapper can host exactly 8*1024/256  = 32 tiles.
; The full tile set of 256 tiles is spread across 8 pages of 8K each.
;
; The algorithm 
;   
; The engine works on the ISR and is based on a strong parallelism between VDP and z80.
; The visible window is 240x160 pixels, plus an extra border area of 16x160 pixels.  
; The screen window is moved in 16 steps corresponding to the 16 scroll positions of R#18.
; The z80 is in charge of plotting, at each ISR a new column of pixels in the right border 
; and a column of blank pixels on the left border on the visible screen.
; In 16 steps, the z80 builds a full new column of tiles on the right and deletes 
; a corresponding area of 16x160 pixels on the left.
; In the meanwhile, at each step, the VDP is in charge of moving 15 slices 16x160 pixels  
; from the visible screen to the hidden page (displacing each slice of 16 pixels) and to  
; build the black border on the right that will appear at page swap (also in this case 16x160 pixels).
; Once the screen offset has reached its maximum, the hidden page is ready and can be 
; swapped with the visible page and the process can restart.
; 
; Devil in the details (1)
; 
; When the z80 starts filling the 16th column of the right border on the visible screen  
; (column n. 255) the vdp has to copy the slice of pixels 16x160 that includes the column
; of pixels being plotted by the z80 from the visible page to the hidden page.
; In order to maximize the parallelism, the vdp starts working before that the z80 has
; started plotting its column, so 1-2 pixels at the top of column 255 get copied before the
; z80 has updated them. 
; Without a workaround, the black pixels would propagate in the screen slice by slice.
; The engine has solved the concurrency problem by filling with valid data the two 2 wrong 
; pixels once they have been copied on column 239 on the hidden page.
; This causes a small loss in performances as the Z80 will copy those two bytes twice:
; once on column 255 in the visible page, once on columns 239 on the hidden page.
; anyway the patch occurs only when the screen offset is equal to 15 and is overall acceptable 
; as we set just 2 bytes in VRAM.
;
; Devil in the details (2)
;
; Why do we split the screen in slices instead of coping the whole 240x160 area to be moved?
; The problem is that the command engine of the VDP is affected by changes in R#18 
; At each change in R#18 occurring while the VDP is coping, there is the possibility that
; a black or white pixel appears. 
; The sole solution is to set R#18 only after the VDP command has been executed.
; This implies that the copy of the screen has to be segmented in tasks that the VDP can 
; complete within a single frame, before R#18 has to be set again.
; The height of the screen (160 pixels) has been chosen in order to have that the VDP ends
; its copy about at the end of the visible area (around line 163) also in NTSC mode
; (in PAL the VDP command is completed much earlier).
; This means that, also in NTSC, a line interrupt at line 160 could safely disable the screen 
; and the sprites, swap page to show a score bar, wait hblank, enable the screen and reset R#18
; without affecting the last VDP command.
; Moreover, the time between line 164 and 192 can be used to execute other VDP commands.
; In the test rom, the RED color bar indicates the z80 usage, the GREEN color bar the vdp usage. 
; Press space to swap between NTSC and PAL and see how things change accordingly.
; 
; Note: use sjasm42c to compile
; In Sjasm42c ":label"  indicates the page in the mapper where label is located.

By Grauw

Ascended (8385)

Grauw's picture

14-06-2019, 00:48

Nice explanation.

p.s. If I leave the demo rom running in the emulator for 1:30, the tiles are offset upwards by a row for a bit. I think the tile map has run a full cycle and doesn’t wrap around proper?

By ARTRAG

Enlighted (6236)

ARTRAG's picture

14-06-2019, 08:15

It is left to the coder to decide how to extend the code (and the map)
I am only covering the algorithm for smooth scrolling (left to right)

By ARTRAG

Enlighted (6236)

ARTRAG's picture

16-06-2019, 10:40

I was wondering that if the position of the glitches in the copy command happen on the pixels being moved when r18 changes one could approximately predict where they will appear and fix them later...

Moreover, I cannot recollect, was it possible to pause a command and make it start again from the point it was?

By PingPong

Prophet (3435)

PingPong's picture

16-06-2019, 11:02

Quote:

Moreover, I cannot recollect, was it possible to pause a command and make it start again from the point it was?

Would be nice, but in my tests if you stop a command in the middle and then re-issue the same writing the cmd register it does not starts exacly as it was stopped.
Rather it does start with some values from the intial value.
For example , the number of pixels processed in a block command will restart from zero.

I do no longer have access to real hw but i think it was when i've done some tests in the past.

By ARTRAG

Enlighted (6236)

ARTRAG's picture

16-06-2019, 13:37

I have found the pages with your experiments
https://www.msx.org/forum/development/msx-development/about-...
BTW now I am curious about what an invalid command code would do while a copy command is executed
:-)

By PingPong

Prophet (3435)

PingPong's picture

16-06-2019, 20:25

invalid command code ? what you mean with invalid command code ? example?

Page 19/20
12 | 13 | 14 | 15 | 16 | 17 | 18 | | 20