Tony Cruise Posted January 20 Share Posted January 20 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 :)). 2 1 Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.