SymbOS MSX multitasking operating system - help needed!

Page 316/398
309 | 310 | 311 | 312 | 313 | 314 | 315 | | 317 | 318 | 319 | 320 | 321

By PingPong

Prophet (3885)

PingPong's picture

12-01-2014, 19:19

Prodatron wrote:

Thanks for the information and the sampel code! I wonder, how long (microseconds) does it take for the VDP to copy an 8x8 square pixel-wise. There is some Z80-overhead between the VDP commands, so I am not sure, if the Z80 sometimes has to wait for the VDP or not. If I would know the exact time for the copy process, I could calculate, if it makes sense to switch to two buffers + plain copy.

unfortunately the vdp blitter is some kind of bizzarre thing. some one had measured timings with a digital device and results are posted here: http://openmsx.sourceforge.net/vdp-vram-timing/vdp-timing.html
just search for "Command engine timing".
from the site there is a table with timings and for LMMM there is also a brief explanation:

the values you read are clock cycles of VDP that is clocked at 21Mhz:

Quote:

I'll explain the notation in this table with an example. Take the LMMM command:

Per pixel the LMMM command needs to:
Read a byte from the source.
Read a byte from the destination
Calculate the result: extract the pixel value from source and destination, combine the two (possibly with a logical operation), insert the result in the destination byte. And write the result back to the destination.
So per pixel, the LMMM command will generate 3 VRAM accesses: 2 read followed by one write. Between these accesses there will be some amount of time.
For LMMM the table lists '64 R 32 R 24 W'. Let's start at the 1st 'R' character, this represents the 1st read. Next there's the value 32 and a 2nd 'R', this means that the 2nd read comes at least 32 cycles after the 1st read. Then there's '24 W', meaning there are at least 24 cycles between the 2nd read and the write. And the initial value '64' means that there are at least 64 cycles between the write and the 1st read for the next pixel.
When moving from one horizontal line to the next in a block command, there is some extra delay. For the LMMM command this takes 64 extra cycles. So 64+64=128 cycles from the last write of a line till the first read of the next line.
Note that all these values are the optimal timing values. The actual delay can be longer because there is no access slot available or the slot is already allocated for CPU access.

By PingPong

Prophet (3885)

PingPong's picture

12-01-2014, 19:29

@Prodatron: so making the calculations we have, for each line, of 8 pixels:
((32+24+64)*8+64)*8=8192 cycles (best case). This is about like 1365 cycles of a z80 @3.5Mhz. If i'm not wrong 390us

By hit9918

Prophet (2921)

hit9918's picture

12-01-2014, 19:32

At least in first version, I would not leave out the check for blitter status.

The cpu in plain outi has bandwidth in similar ballpark as blitter copy.
When blitter is doing the slow nibblewise LMMM op, cpu might overtake.

First, it may look like cpu doesn't overtake, and the day you print a wider char,
cpu overheads get lower and the thing crashes.

Also, MSX got different machines.
The emulator blitters may not have cycle exact timing, too kind of a "different machine".

Also, first time entering the char printing, the blitter may still be busy with some other huge blit of previous GUI work.

By Prodatron

Paragon (1808)

Prodatron's picture

12-01-2014, 21:12

390us is a lot... So much that currently the Z80 will probably wait for the VDP. Seems, that I really should try out the suggested solution.
@hit9918: I can't use OUTI commands for filling the rectangle, as the font graphic has to be generated on the fly out of the font matrix data. So before each OUT there are some bit-shifting-commands and something like this. Maybe in this case I could even work with only one buffer.

By PingPong

Prophet (3885)

PingPong's picture

12-01-2014, 23:04

Prodatron wrote:

390us is a lot... So much that currently the Z80 will probably wait for the VDP. Seems, that I really should try out the suggested solution.
@hit9918: I can't use OUTI commands for filling the rectangle, as the font graphic has to be generated on the fly out of the font matrix data. So before each OUT there are some bit-shifting-commands and something like this. Maybe in this case I could even work with only one buffer.

@prodatron: maybe my calculations are totally wrong. check the page i've linked, please.

By hit9918

Prophet (2921)

hit9918's picture

13-01-2014, 00:17

below I tried monochrome font, it is 3 times slower.
so GUI is 3 times slower when font is not in vram representation.

	;one line of font
	
	ld a,(hl)
	inc hl
	ld b,4	;4*2 pixels
loop:
5	rlca
8	jr c,l1x
;0x
5	rlca
8	jr c,l01
;00
14	out (c),e
14	djnz loop
--
54, best case like 3 outi per byte

	jp exit
l01:
	ld a,ixl
	out (0x98),a
	djnz loop
	jp exit	
l1x:
	rlca
	jr nc,l10
;11
	out (c),d
	djnz loop
	jp exit
l10:
	ld a,ixh
	out (0x98),a
	djnz loop
	jp exit

By Prodatron

Paragon (1808)

Prodatron's picture

13-01-2014, 19:26

A little in-between question:
Does anyone still has Caros OCM SD-card driver for SymbOS, which is mentioned here:
http://www.msx.org/forum/development/msx-development/symbos-msx-multitasking-operating-system-help-needed?page=279 (8.post)
The ZIP ( http://www.msx.org/www.caro.k66.ru/files/fdocm.zip ) doesn't seem to exist anymore.
I am afraid that I missed that at this time.

By NYYRIKKI

Enlighted (5917)

NYYRIKKI's picture

13-01-2014, 19:30

LOL, I think you mean this one:
http://www.caro.k66.ru/files/fdocm.zip

:)

By Prodatron

Paragon (1808)

Prodatron's picture

13-01-2014, 19:54

Crazy Crazy I am getting old... yes that is what I mean, thanks! LOL!

By edoz

Prophet (2437)

edoz's picture

14-01-2014, 10:22

It would be nice to have a driver also for the MegaFlashROM SCC+ SD. I think at this moment the most SD device?

Page 316/398
309 | 310 | 311 | 312 | 313 | 314 | 315 | | 317 | 318 | 319 | 320 | 321