Artemio's 240p Test Suite

[+nanochess]

Hi all.

 

A few days before Christmas, my good friend @Artemio convinced me to port the 240p Test Suite to Colecovision.

 

This test suite helps you to tune your TV, check backlit, synchro errors, aperture/width, color adjustment, etc. Not all tests of the original suite could be made with the TMS9928 but most are there, for example, the NTSC 75% luminance color bars aren't possible.

 

Also, I've added a few extras like a controller test and a CRC32 for checking the BIOS signature (SHA1 for MSX).

 

The full source code goes under GPLv2 as the original, and the most updated version will be available from: https://github.com/nanochess/240pTestSuite_colecovision/

 

For non-tech-versed users, I'll simply drop here the current ROM and manual.

 

Enjoy it!

 

suitecv.rom

Suite_manual.txt

[+cjherr]

Thank you, sir.

[Falonn]

This looks like it will be a great resource for the community, thanks!

 

As someone that's been thinking of dipping my toes in Colecovision programming for a while now, I was just browsing the code and spotted this curious double call to vdp_no_interrupt.  Is there some quirk of the hardware that requires it to be called twice?  Is it in case there is an interrupt during the first call?  Does the VDP interrupt flag need to be cleared by the first call before the interrupt is actually disabled in the second call?  Thanks!

 

(And, by way of introduction since I don't believe we've ever spoken directly before: I was just appreciating your winning IOCCC submissions last week.  All of your work is very impressive!)

[+nanochess]

BTW if someone tests this in Europe with a 50hz Colecovision, please provide me the CRC32 hash of the BIOS, it should appear as "Unrecognized BIOS".

[+nanochess]

1 hour ago, Falonn said:

This looks like it will be a great resource for the community, thanks!

 

As someone that's been thinking of dipping my toes in Colecovision programming for a while now, I was just browsing the code and spotted this curious double call to vdp_no_interrupt.  Is there some quirk of the hardware that requires it to be called twice?  Is it in case there is an interrupt during the first call?  Does the VDP interrupt flag need to be cleared by the first call before the interrupt is actually disabled in the second call?  Thanks!

 

(And, by way of introduction since I don't believe we've ever spoken directly before: I was just appreciating your winning IOCCC submissions last week.  All of your work is very impressive!)

In the case of a RESET, and as the RESET pin of the VDP isn't connected, you cannot be sure of the state of the VDP address register (written in two bytes, it could be just after the first byte). But this state is reset after a read of the VDP status register. So if the first call didn't make it right, the second call will correct it.

 

Thanks! I enjoyed the IOCCC at the time. I've fond memories of it.