Colecovision VRAM Timings on Real Hardware (Ensure Testing on NTSC and Pal)

[Tony Cruise]

This is a general information post for any developers looking at releasing new games for the Colecovision consolidating various advice I have given a number of developers and a number of recent releases that have made it to physical release that have had issues on some real consoles.

Testing

Testing is hard, and a painful experience, and takes a long time, requiring a lot of patience. My thanks and support goes out to anyone that has given their time assisting any of the Colecovision developers with testing their titles.

Most important points to consider about testing:

- Always have multiple testers and ensure they are based in different regions i.e. both Pal and NTSC

- Always ensure pre-release testing is conducted on real hardware (so this means on a real Colecovision from both Pal and NTSC regions)

- Ensure at least one of your testers plays the game throughly multple times and that they video their entire test runs  (and you should watch these run throughs in full - you will be amazed at what you notice watching someone else play your game) - this means you need testers who can do well at a game to be able to get through multiple levels - this is one the hardest jobs and requires a large commitment from any tester, but it is vital e.g. one of my wonderful testers played Cavern Fighter starting on easy and got through the Caverns twice to then start the Hard run through where the game crashed. The bug only occurred if the game was played through in that sequence, starting on the Hard level did not make the bug surface.

- You do need to also test on the Collectorvision Phoenix (both firmwares) as there are now quite a large number of users with these units - and it's emulation is not perfect (or maybe too perfect see below)

- It's a good idea to test a game that does not need the SGM on a physical console with the SGM both not plugged in and plugged in.

- You will never get the game perfect (we all get caught by this - look at modern releases nowadays as well!)

Catering For Real Hardware

We build our games using modern desktop systems and some wonderful emulators (including the wonderful FPGA hardware emulation of the Phoenix), but these can never replicate the original components in a physical console. Remember these components are all aging and their timings will degrade.  Also Coleco used the cheapest VRAM chips they could find at the time, so games need to take into account longer timings/patience with the VDP.  Emulators are simulating the perfect hardware so you should only use them to test your game in it's early stages, you must test on real hardware (both Pal and NTSC).  Also note that most of the emulators default to 60Hz i.e NTSC, they can be changed to also run at 50Hz (Pal), use this!

MSX/SG-1000 Ports

Quite a few releases are by developers who take an existing MSX or SG-1000 game rom and 'port' it to the Coleco.  The original author in me does not approve of this, as you are re-using another authors works (pretty much most of the original code and art asssets) without their permission, but that is just me I am a bit stuck in my ways, and I know a lot of people have no problem with this and I know my way of writing games from scratch takes a lot longer.

All I will say if you do this, please remember that there is a quality difference between the components used in both MSX and SG-1000 and the components used in a Colecovision, so you can't just remap the port calls in the game and change where the Ram is and call it a done.  You need to actually ensure that the original game allows enough time for the slower Colecovision VRAM.  And also remember these original games had their own bugs, be nice if you fixed them as well.

Once recent example (which does not work on my Pal console at all) is a SG-1000 port that tries to boot into the game way too fast, probably because that's what the original code did and it was fine on the SG-1000. You have to wait the appropriate amount of time for the Colecovision hardware to warm-up.  There is a reason that the Coleco BIOS has such a delay in the start-up (as well as to push the logo of course). And yes it is possible to skip the BIOS logo in your game settings (I do in mine), but doesn't mean you shouldn't make sure you don't overtax the VDP at startup.

NMI VDP Access vs non-NMI VDP Access

It is still possible for VDP reads (and writes with extreme care) to occur outside of the NMI routine, but you need to allow for longer timings i.e. the VDP is after all busy at this time.

To read from the VDP outside of the NMI you need to ensure three things:

- a NMI interrupt does NOT occur between you setting the 1st and 2nd byte of the VRAM address - solution ensure the use of DI and EI around your address set method

;
; Set read to Video Ram
; HL = VRAM Address
SETRD:
    DI
    LD A,L
    OUT (CTRL_PORT),A
    LD A,H
    AND 3Fh
    OUT (CTRL_PORT),A
    EI
    RET

- you allow at least 14 cycles between setting the address and reading your first value.

- if you are reading a number of bytes, ensure at least one NOP instruction (4 cycles) after the IN command, this along with your instruction(s) to save the value and continue your loop should be enough time.

Writing to VDP outside of a NMI should only really be done with rendering (and the NMI) turned off or the very brave.

 

Most important keep writing new games for the Colecovision, myself (and many others) will always be looking forward to supporting you and playing them (on our original Colecovision hardware for as long as possible :)).

 

[+-^CrossBow^-]

This is how all testing for new games for any vintage/classic console should be handled. This is somewhat standard at least in the 7800 world and I know that when I was part of the testing for Intellivision home brews, I was testing on all of my various models. Even through all of that, a pretty nasty bug still made it through on one of those games due to the fact that most of us testers were only playing 1 player games. The bug would only happen in 2 player modes. So even with all the hardware and emulation testing that was being done, there was still that additional requirement of also having to find a 2nd player willing to play with you for testing in that game. Something I wasn't able to do at that time.

 

 

[ChildOfCv]

16 hours ago, Tony Cruise said:

Also Coleco used the cheapest VRAM chips they could find at the time, so games need to take into account longer timings/patience with the VDP.

That's really irrelevant to game development.  The VDP drives the RAM at the same speed, expecting it to keep up, with no regard to its actual capability.  If it doesn't keep up, graphics glitches happen.  The only remedy for that is to replace the faulty chip(s).

[+-^CrossBow^-]

18 minutes ago, ChildOfCv said:

That's really irrelevant to game development.  The VDP drives the RAM at the same speed, expecting it to keep up, with no regard to its actual capability.  If it doesn't keep up, graphics glitches happen.  The only remedy for that is to replace the faulty chip(s).

And on that note, the games need to be tested to be sure they will with +5v upgraded VRAM chips for those that have had to replace the original VRAM in their consoles.

 

[Tony Cruise]

19 hours ago, -^CrossBow^- said:

This is how all testing for new games for any vintage/classic console should be handled. This is somewhat standard at least in the 7800 world and I know that when I was part of the testing for Intellivision home brews, I was testing on all of my various models. Even through all of that, a pretty nasty bug still made it through on one of those games due to the fact that most of us testers were only playing 1 player games. The bug would only happen in 2 player modes. So even with all the hardware and emulation testing that was being done, there was still that additional requirement of also having to find a 2nd player willing to play with you for testing in that game. Something I wasn't able to do at that time.

 

 

Yes exactly right, you can never underestimate how much time and effort it takes to test.  And it reinforces the need to have a dispursed group of testers so that you can increase the chance of one of them doing that one different thing that no one else thought of.

[Tony Cruise]

17 hours ago, ChildOfCv said:

That's really irrelevant to game development.  The VDP drives the RAM at the same speed, expecting it to keep up, with no regard to its actual capability.  If it doesn't keep up, graphics glitches happen.  The only remedy for that is to replace the faulty chip(s).

But the majority of the hardware you are targetting with the Coleco have the under spec Ram chips, that have now aged, you can't trust the fact that your code works on an emulator that it will work on real hardware.  You of course can't cater for truly faulty hardware (a machine like that should show glitches for the majority of titles, not just one game), but obviously with the number of titles released recently not working on real hardware there is a general problem of not testing on real hardware, especially on Pal machines.

Coleco/SG/MSX share similar hardware, but they are not the same, assuming timings are the same between them is a common mistake.

There is even an specific example from the MSX world, with the Toshiba VDP being a clone chip, rather than an official one and having different timings, which only surface if you are pushing things.

[ChildOfCv]

22 hours ago, Tony Cruise said:

But the majority of the hardware you are targetting with the Coleco have the under spec Ram chips, that have now aged, you can't trust the fact that your code works on an emulator that it will work on real hardware.  You of course can't cater for truly faulty hardware (a machine like that should show glitches for the majority of titles, not just one game), but obviously with the number of titles released recently not working on real hardware there is a general problem of not testing on real hardware, especially on Pal machines.

Coleco/SG/MSX share similar hardware, but they are not the same, assuming timings are the same between them is a common mistake.

There is even an specific example from the MSX world, with the Toshiba VDP being a clone chip, rather than an official one and having different timings, which only surface if you are pushing things.

Still, this is irrelevant to the programming part.  The VDP requires a specific clock, somewhere around 10.3MHz, whether NTSC or PAL.  It accesses memory with a specific timing because it has to draw the screen 30/25 times per second, so it keeps racing through the same memory 30/25 times per second, making thousands of memory accesses, completely independent of the program that's running.  So if the memory can't keep up, you're already screwed.

 

For memory writes, the program finally has some effect, but it goes through the VDP, not direct to the memory, so the memory is still beholden to the VDP's timings, not your program's.  If the memory can't keep up, I would never suggest that the solution is to nerf your program, but to fix the memory so that it's again in spec.

 

Clone chips may be something to look out for if you feel charitable.  But if you're designing a fast-paced shoot-em-up and some knock-off can't keep up, it's not your program's fault, and you shouldn't feel obligated to make it work.

[youki]

Deep testing can take more the time than the development itself!

 

It is very hard to find good testers. One you find one, do all you can to keep it!!!

 

But it is very time consuming for the tester itself , and this kind of people have also a real life...  

 

The worst is that you have to find a tester that have different hardwares....   or multiple good testers...    

 

It is almost impossible when you release a game to be sure it will work on all hardwares.

 

Personally , i only target ,  Stock colecovision PAL/SECAM/NTSC in good condition .   However we do also few tests on Phoenix and Homebrew Vision.

 

In my games i try to not use very tricky things so i have good hope if it works on stock colecovision , it should work on Adam and others. But all can happens...

 

And don't count on the publisher to do your full beta testing. (they have sometime not enougth time or don't want to invest too much time in that, or have the means or the knowledge to do that... (exception for TeamPixelBoy who really invest on that)) .

 

 

Edited January 22, 2023 by youki