Strange issue on real HW

Page 5/20
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10

By ARTRAG

Enlighted (6844)

ARTRAG's picture

17-04-2015, 23:50

I've removed the 0xC9 at 0x0038 replacing it with a fake ISR and removed the ei halt section.
Still no success on my msxTR, but if I enable only the vsync and not the lineint, I see for short time a green bar that tends to disappear after few seconds.
The new files are on github

By ARTRAG

Enlighted (6844)

ARTRAG's picture

18-04-2015, 12:16

The next step will be move the score bar on top inverting the use of vblank and lineint
I am fiddling around hoping to remove the issue but it is a blind search...

By ARTRAG

Enlighted (6844)

ARTRAG's picture

18-04-2015, 15:30

hit9918 wrote:
Quote:

It works only at 50 he due to exact timing of some actions
no point in testing at 60hz

instead of "no point in it" I would say it is serving the synchronization bug on a golden plate in a emu config Smile

No point because of the vdp timings. At 60Hz the VDP cannot scroll the screen at 1 pixel per frame.
More precisely, the time spent by the vdp to move a 16x176 area and tracing a box 1x176 is longer than the 1/60 sec.
Thus the hang would happen also on turbo cpus.

By ARTRAG

Enlighted (6844)

ARTRAG's picture

18-04-2015, 18:09

Humm... I have good news and bad news
Good news:
Fiddling around now I have a working configuration,
Bad news:
Now I can see on real HW a bunch of new glitches that the emulators do not show
:-(

Anyone willing to report what he sees on his HW ?
https://github.com/Maneldemo/shooter_scr8_asm/

On turbo machines pressing CTRL at boot you will start in standard mode

What I see on msx Turbo R (z80 mode):
1) strange spare pixels in the background
2) screen bumping of 1 pixel up and down randomly
3) sprites randomly displaced and aliased

On msx Turbo R in R800 mode effect 3) does not appear

By MsxKun

Paragon (1101)

MsxKun's picture

18-04-2015, 18:03

Welcome to the real world Cool

By ARTRAG

Enlighted (6844)

ARTRAG's picture

18-04-2015, 18:05

Spare pixels are due to changing r#18 while the vdp is coping.
or someone discovers a workaround to prevent this glitch or I have to remove the score bar....
but extending the screen height to 192 pixels could be too much for the poor vdp....

By MsxKun

Paragon (1101)

MsxKun's picture

18-04-2015, 18:13

Ok, let's test the thing on my 2+ (just to try a different machine) and see what happens...

By MsxKun

Paragon (1101)

MsxKun's picture

18-04-2015, 18:33

Tested. I see the screen going to gray-blueish background (and it copies some gfx tiles too) and then everything goes black and there is no image, only music.

Ok, that was the OLD rom Tongue Trying the last one....

By MsxKun

Paragon (1101)

MsxKun's picture

18-04-2015, 18:36

On the new ROM I can confirm points 1 and 2 happens. Didn't notice any point 3 yet.
But sometimes a bigger version of point 2 happens, where sprites and glitches can happen even under the score bar.

By Grauw

Ascended (10581)

Grauw's picture

18-04-2015, 21:05

ARTRAG wrote:

Spare pixels are due to changing r#18 while the vdp is coping.
or someone discovers a workaround to prevent this glitch or I have to remove the score bar....
but extending the screen height to 192 pixels could be too much for the poor vdp....

Yes this happens. You could time your copies to not coincide with the r#18 change… Or use sprites to display the score.

Page 5/20
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10