Fun with VDP status register

[+nanochess]

This is a test program for checking what happens with the Colecovision VDP status register when it is polled and also collision bit and 5th bit as it allows to put sprites on screen

 

I developed it because several users had doubts about its behavior here http://atariage.com/...ooth-scrolling/ (see posts 120 and towards)

 

This program is a simple one that polls the VDP status register and puts the hexadecimal value in the screen starting at top corner left. When it receives a byte that includes bit 7 set (VDP interrupt) it puts an asterisk and reinits position at top left.

 

No interrupts activated, mode 2 ($0000-$17FF character set, $1800-$1fff sprites, $2000-$37ff color table, $3800-$3aff screen, $3f80-$3fff sprite table reset to $D0)

 

I've made it as fast as possible and then inserted some delays so each hexadecimal value corresponds to (more or less) one screen line, so I have around 259 values in screen.

 

Beside I've included an option to erase all sprites from screen or put up to five sprites that can be displaced with the joystick to test for collision and 5th sprite.

 

I've seen following:

 

1. bits 4-0 shows LAST sprite processed or number of 5th sprite (the last sprite processed can be the sprite containing the Y-coordinate set to $D0). I've seen variations when there are various sprites on screen (like a ramp over my status screen,) probably because VDP updates it as it process sprites.

2. bit 5 (collision bit) is exact and there is no failure, besides it is not affected by offscreen sprites (matthew180 right on this)

3. bit 6 (5th sprite) also is exact and there is no failure.

4. bit 7 (interrupt bit), THERE IS A RACE CONDITION (marc.hull is right about this,) each second or two seconds, with continuous polling (and including generous delay to write status to screen) at least one VDP interrupt is lost, so my status screen overflows.

 

I hope this information is useful for everyone.

 

With controller 1 press * (asterisk) to erase all sprites (it starts in this state)

 

Press 1 to display sprite 1.

 

Press 2 to display sprite 2.

 

Press 3 to display sprite 3.

 

Press 4 to display sprite 4.

 

Press 5 to display sprite 5.

 

Use joystick to move last displayed sprite.

 

By the way, it would be greatly appreciated if someone with PAL Colecovision could check if same behavior happens, specially the VDP interrupt race condition.

cv_vdp_status_test.rom

Edited July 22, 2013 by nanochess

[+5-11under]

Is the source code in C or assembler?

I was never able to get the collision detection to work, but maybe that was because I was using interrupts... although I tried testing the bit both inside and outside the interrupt... so... care to share the source code so I can try again?

[+nanochess]

Is the source code in C or assembler?

I was never able to get the collision detection to work, but maybe that was because I was using interrupts... although I tried testing the bit both inside and outside the interrupt... so... care to share the source code so I can try again?

It's in assembler, I don't think is it very useful as it doesn't use interrupts. Also I'm afraid that my code is all commented in Spanish.

 

I'll see if I can arrange it for public (not promising anything)

 

The collision bit works just fine. On NMI interrupt read the VDP status and check it (note that it only indicates collision, not number of sprite)

 

Just two extra things, any sprite not used should have a Y coordinate in non-visible position of screen (like $D1) and/or finish the table of sprites with a sprite with Y coordinate equal to $D0 so VDP doesn't process further sprites.

 

Even sprites with transparent color are taken in account for collision (internally the VDP checks the pixels of the bitmap of each sprite so color doesn't matter,) so filling all sprite table with $00 would create instantaneous collision (because sprites are in visible coordinate and one over other even though using transparent color)

[Kiwi]

I may be able to read it as is. I can follow it and I know a bit of Spanish. Of course if there's something complicated, google translate to the rescue .

[F-Cycles]

This program is a simple one that polls the VDP status register and puts the hexadecimal value in the screen starting at top corner left. When it receives a byte that includes bit 7 set (VDP interrupt) it puts an asterisk and reinits position at top left.

 

No interrupts activated, mode 2 ($0000-$17FF character set, $1800-$1fff sprites, $2000-$37ff color table, $3800-$3aff screen, $3f80-$3fff sprite table reset to $D0)

 

I've made it as fast as possible and then inserted some delays so each hexadecimal value corresponds to (more or less) one screen line, so I have around 259 values in screen.

 

Beside I've included an option to erase all sprites from screen or put up to five sprites that can be displaced with the joystick to test for collision and 5th sprite.

 

I've seen following:

 

1. bits 4-0 shows LAST sprite processed or number of 5th sprite (the last sprite processed can be the sprite containing the Y-coordinate set to $D0). I've seen variations when there are various sprites on screen (like a ramp over my status screen,) probably because VDP updates it as it process sprites.

2. bit 5 (collision bit) is exact and there is no failure, besides it is not affected by offscreen sprites (matthew180 right on this)

3. bit 6 (5th sprite) also is exact and there is no failure.

 

Thanks for this test! Yes very useful. I though also this status value would be changing according to the scanline we are.

 

I read somewhere that collision bit was not working on Coleco Vision which get old.. because of some power problems which are minor!? I would like to know if that's true...

 

Hum.. the collision in your test seem to happen only when the pixels which are on are touching each other? Well, I am testing in an emulator (BlueMsx)... Maybe on the real hardware the collision happen as soon the 2 square overlap!? Is that what you observe?

 

Sorry I end up with more questions than answer.. ^_^

[+5-11under]

Any source code would be appreciated.

[F-Cycles]

Any source code would be appreciated.

 

Attached source code + .rom files.

---> Oupss.. sorry, I post my src code + screen shot in wrong thread..

 

 

1. 1 Sprite in 32x32 (by setting the MAG flag to 1) + changing colors

 

--> In the emulator, I never saw one line with 2 colors.

 

2. 1 Sprite and modifying the X position from 0 to $D0.

 

--> In the emulator, I never saw on one scan line, the 2 sprites.

 

3. 1 Sprite and modifying the X position.. increment the value initially set to $0 and decrementing the 2nd value which was set to $d0.

 

--> That one was made for fun...

 

4. 2 Sprites at fixed position and modifying the MAG flag...

 

--> I never saw in one scan line, one which will be MAG ON and the 2nd sprite being MAG OFF...

 

Those tests flickers a lot... so they might be very hard to see on the real hardware at normal speed.

I recommend to use a camcorder (60 FPS) then look at the frames in slow motion.

sprite_tests_by_fcycles.zip

Edited July 23, 2013 by F-Cycles

[+nanochess]

Thanks for this test! Yes very useful. I though also this status value would be changing according to the scanline we are.

 

Great!

 

I read somewhere that collision bit was not working on Coleco Vision which get old.. because of some power problems which are minor!? I would like to know if that's true...

 

I didn't see that and I think my Colecovision is pretty old.

 

Hum.. the collision in your test seem to happen only when the pixels which are on are touching each other? Well, I am testing in an emulator (BlueMsx)... Maybe on the real hardware the collision happen as soon the 2 square overlap!? Is that what you observe?

 

Also in real hardware the collision only happens in touching pixels.

[F-Cycles]

I didn't see that and I think my Colecovision is pretty old.

 

Also in real hardware the collision only happens in touching pixels.

 

Good to know! So, it give me hope to use it then.

 

Oh, I found it.. look to the thread: Eye on Coleco, But Many Questions...

 

a quote from PkK:

However, this functionaily is not commonly used by games. And unfortunately, it seems to be one of the first things to fail when the voltage supply at the graphics chip is too low (low voltage is a common problem on ColecoVisions due to voltage switch dirt buildup and power supply degradation). So if you use it be prepared for players complaining that your game doesn't work even though other games are working on their systems.

Edited July 23, 2013 by F-Cycles

[+nanochess]

And PkK is completely right.

 

Just I've wrote another test that can be found here: http://atariage.com/...25#entry2797077

 

This test (with idea from Tursi) probes that all bits of VDP status register can fail miserably when polling is used, specially after a while (chip becoming hot?) or maybe because of low voltage as PkK says.

 

Still would remain to test stability when used only in interruption mode.

Edited July 24, 2013 by nanochess

[F-Cycles]

This test (with idea from Tursi) probes that all bits of VDP status register can fail miserably when polling is used, specially after a while (chip becoming hot?) or maybe because of low voltage as PkK says.

 

Still would remain to test stability when used only in interruption mode.

 

The over temperature is an interesting hypothesis. Pooling RAM value to be read on the video chip give him more work to be done. Temperature usually vary according to exponential curve... When you see the fail occuring.. can you try to shoot air pressure on the chips to lower the temperature down?

[+nanochess]

The over temperature is an interesting hypothesis. Pooling RAM value to be read on the video chip give him more work to be done. Temperature usually vary according to exponential curve... When you see the fail occuring.. can you try to shoot air pressure on the chips to lower the temperature down?

I don't have pressurized air readily available, besides I would have to open my Colecovision... Hmmm! I think better not.

Edited July 24, 2013 by nanochess

[+nanochess]

Attached source code + .rom files.

---> Oupss.. sorry, I post my src code + screen shot in wrong thread..

 

 

1. 1 Sprite in 32x32 (by setting the MAG flag to 1) + changing colors

 

--> In the emulator, I never saw one line with 2 colors.

 

2. 1 Sprite and modifying the X position from 0 to $D0.

 

--> In the emulator, I never saw on one scan line, the 2 sprites.

 

3. 1 Sprite and modifying the X position.. increment the value initially set to $0 and decrementing the 2nd value which was set to $d0.

 

--> That one was made for fun...

 

4. 2 Sprites at fixed position and modifying the MAG flag...

 

--> I never saw in one scan line, one which will be MAG ON and the 2nd sprite being MAG OFF...

 

Those tests flickers a lot... so they might be very hard to see on the real hardware at normal speed.

I recommend to use a camcorder (60 FPS) then look at the frames in slow motion.

 

At least in BlueMSX you cannot see changes in one line, because as far as I know it renders screen line by line. OpenMSX renders pixel by pixel but it doesn't support Colecovision.

 

You should test in a real Colecovision.

[F-Cycles]

At least in BlueMSX you cannot see changes in one line, because as far as I know it renders screen line by line. OpenMSX renders pixel by pixel but it doesn't support Colecovision.

 

You should test in a real Colecovision.

 

Well, apparently it get updated more than a screen line... I asked on BlueMSX forum and someone point me to this article:

http://www.danielvik.com/2010/04/cycle-accurate-computer-emulation.html

 

But, I agree with you.. I should test on a real hardware.