Timing of BIOS routines, such as BIOS_WRTVRM

Page 1/3
| 2 | 3

By albs_br

Expert (70)

albs_br's picture

10-07-2020, 08:14

I did a lot of research, but found nothing.
Is there any place where I can find the timing of BIOS routines, such as BIOS_WRTVRM?
How many T-States it uses? It's a crucial information to optimize code.

Thanks

Login or register to post comments

By SjaaQ

Expert (119)

SjaaQ's picture

10-07-2020, 08:23

I don't think that exists. That why everybody writes their own code to do this. And even if it existed, I could be different on another machine.

To write your own code, see for examples: http://map.grauw.nl/articles/vdp_tut.php#vramtiming

By theNestruo

Master (159)

theNestruo's picture

10-07-2020, 12:44

Get the source code from here (for example; different machines may have different source... and C-BIOS will probably be different too).

Paste it here and measure it: 97 t-states + 7 wait states = 104 total time (10 bytes)

By theNestruo

Master (159)

theNestruo's picture

10-07-2020, 14:51

Sorry, page went down before I was able to edit...

Timing should include both A07CD and A07DF routines (because of the call)... The correct values are: 175 T-states (total time), 23 bytes.

For reference, the code is:

WRTVRM: jp      A07CD                   ; 004DH
; (...)
A07CD:  push    af
        call    A07DF
        ex      (sp),hl
        ex      (sp),hl
        pop     af
        out     (098H),a
        ret
; (...)
A07DF:  ld      a,l
        di
        out     (099H),a
        ld      a,h
        and     03FH
        or      040H
        out     (099H),a
        ei
        ret

By santiontanon

Paragon (1032)

santiontanon's picture

11-07-2020, 01:22

Yep, I think you'll have to time it yourself, for example as theNestruo suggests. But as SjaaQ points out, notice that different MSX models have different BIOS implementations, and thus timings will be different.

By Grauw

Ascended (9181)

Grauw's picture

11-07-2020, 01:55

That's quite a wait (the two ex (sp),hl's).... the ei + ret + pop af should already be enough, the outs are 40 cycles apart (11 μs), well over the 8 μs required by the VDP. And even that is actually only needed for reads, and consecutive writes, not for a single write...

By albs_br

Expert (70)

albs_br's picture

11-07-2020, 02:21

Well, anyway, 175 ara a lot of states, I will optimize my code.
I have a subroutine called PutSprite, which sets all four bytes of the sprite attr table, and normally only X and/or why are really changed. I am wasting a lot of time rewriting the same value of color and pattern.

Thanks everyone for the help.

By thegeps

Champion (502)

thegeps's picture

11-07-2020, 09:34

Best way to manage sprites is to have a 128 bytes buffer on RAM apply there all the modifications and THEN copy all 128bytes to VRAM all togheter, writing consequentially. If you do it during vblank you don't even have to worry about timing limits and you cannuse otir or, even better, unrolled otir...

By albs_br

Expert (70)

albs_br's picture

11-07-2020, 15:57

Nice advice. Is vram slower than ram?

By Grauw

Ascended (9181)

Grauw's picture

11-07-2020, 16:11

The RAM itself isn’t, but access is shared with the VDP so the CPU writes are buffered until an “access slot” becomes available. Additionally, sequential access is relatively fast but random access requires that you re-set the address. If you need random access to the sprite attributes it may indeed be more convenient to use an 128-byte buffer in RAM and transfer it in one go when you’re done. (I myself don’t use such a buffer, rather I call all the sprite update routines in order and write sequentially.)

By albs_br

Expert (70)

albs_br's picture

11-07-2020, 16:17

Also, how do I know if I'm on vblank, to make this 128 bytes copy?

Page 1/3
| 2 | 3