BitBuster depack in VRAM

Paladin (899)

09-03-2023, 23:49

I think I found the problem with Pletter VRAM decompressor.
The timing between a out(n),a and in a,(n) was 17 t-states (with a nop in between) but don't seem enough time delay to access VRAM for Screen 2 on a real MSX 2 (a Panasonic FS-A1).
With a second nop in between, all the visual glitches vanished.
Yet, according to Grauw's MAP, minimal VRAM access timings for Screen 2 on MSX 2 is supposed to be 15 t-states.
Any idea what is going on?
I find it hard to believe that both MAP and openMSX are wrong about VRAM access times, but that's what I observe.

By aoineko

Paladin (899)

11-03-2023, 17:30

I was able to confirm on a second real MSX (a Philips NMS 8250) and I have the same issue.
Without a 2nd nop between the out(n),a and the in a,(n) I have visual glitches on a real MSX while I don't have the problem with openMSX.

The strange thing is that doing these VRAM accesses with the screen display on or off seems to have no impact on whether glitches are present or not (only the number of nops makes a difference).

This contradicts all what I learned about VDP timing... I'm a little confused. :-/

By DarkSchneider

Paladin (990)

11-03-2023, 20:47

I remember having that issue with SCREEN 4, having glitches if using unrolled OUTI for writing but all nice with OTIR.
So for tile modes with sprites enabled I think the INIR/OTIR version must be used for linear operations.
If we think about it, on tile mode it has to access at the same time to:
- Tile pattern.
- Tile Color.
- Sprite Pattern.
- Sprite Color.
- Sprite attribute table.

Those are more accesses than in bitmap modes as there is no tile color, and probably the reason that needs more time between CPU accesses.

What I see rare is that disabling screen it happens anyway.

By aoineko

Paladin (899)

12-03-2023, 19:13

With Screen 4 the minimum time between two accesses to the VRAM is supposed to be 15 T-States, whereas the outi instruction takes 18 T-States. It is very strange that you had problems in this screen mode.

I thought the timings given on the MAP website were the worst case scenario.

By Bengalack

Paladin (721)

13-03-2023, 07:33

Seems like what I have reported earlier, here: https://github.com/openMSX/openMSX/issues/1402#issuecomment-...

Real MSX can’t go as fast as openmsx allows you to, and those 15 t-states seems wrong.

By sd_snatcher

Prophet (3646)

13-03-2023, 11:11

DarkSchneider wrote:

I remember having that issue with SCREEN 4, having glitches if using unrolled OUTI for writing but all nice with OTIR.

What MSX model were you using?

By DarkSchneider

Paladin (990)

13-03-2023, 14:27

sd_snatcher wrote:

DarkSchneider wrote:

I remember having that issue with SCREEN 4, having glitches if using unrolled OUTI for writing but all nice with OTIR.

What MSX model were you using?

Philips VG 8235, also tested on a Mist FPGA without enabling the fast VDP.

I think for tile mode with sprites the timing is just the 21 of the OTIR/INIR. Or maybe this could have some relevance? (from those instructions):

Quote:

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