opcode Posted October 9, 2012 Share Posted October 9, 2012 Since the SGM specs are now set in stone, I think it is a good time to start publishing the technical info so that homebrewers wanting to develop to it can get started. This is the first part of a two parts technical discussion about the SGM and in this part I am going to cover the RAM expansion. As most of you are well aware, ColecoVision work RAM is limited to 1KB, mapped from 6000h to 63FFh, and then mirrored to 6400h until 7FFFh (so 8 times). The ColecoVision also includes 8KB of BIOS routines, mapped from 0000h to 1FFFh. The SGM expands the work RAM from 1KB to 32KB maximum. Here is how: 24KB can be mapped from 2000h to 7FFFh. When mapped, the internal 1KB of RAM is no longer accessible. All legacy software still works normally under this mode. However, since the SGM must also be compatible with the ADAM, the 24KB of extra RAM is NOT enabled by default. In order to use that expanded memory in a ColecoVision system, the programmer must first enable it. But before doing so, you also need to make sure the module isn’t attached to an ADAM system, otherwise there may be a memory conflict with potential for damaging the ADAM and/or the SGM. So the first step is to check if the 24KB are already available. If they are, then you have an ADAM system, and the SGM expanded memory should NOT be enabled. If no memory is found (in the 2000h-5FFF range), then it is a ColecoVision system and the expanded memory can be enabled. To do so, set bit0 in I/O port 53h to 1, like this (in assembly): LD A,00000001b ; OUT(53h),A You can also map 8KB of RAM (for a total of 32KB) to address range 0000h-1FFFh. However, when doing so, the ColecoVision BIOS will be disabled. RAM and BIOS can be mapped back and forth, though. To map RAM to the BIOS area, simply set bit1 in I/O port 7Fh to “0”. In order to keep full compatibility with ADAM systems, all bits in I/O port 7Fh must be set to specific values, though. Here is how you should set the port: if you want the BIOS, set the port to “0001111b”. If you want RAM instead, set the port to “0001101b” (see example above on how to do that in Assembly). Make sure you respect those values, or your game may not work on ADAM systems. I plan to release complete ASM libraries for detecting ADAM, SGM, and then setting RAM appropriately. I recommend using those libraries, so that we eliminate the risk of enabling the SGM expanded RAM on ADAM systems. Here are the steps required to initialize a Super Game Module game: 1) When initializing your game, use RAM in the 6000h-63FFh range, because the SGM expanded RAM is disabled by default, and you must make sure it isn’t an ADAM before enabling it. 2) Run some memory tests to establish if RAM is already present in the 2000h-5FFFh. If it is, then you have an ADAM system. In that case, DO NOT enable the expanded RAM. Go to step 4 3) If no memory is found, then we have a ColecoVision system, and the SGM expanded RAM can be enabled. Do so by setting I/O port 53h to 01h. You shouldn’t disable expanded RAM after that (i.e., do not access I/O port 53h again after initializing it). 4) Now that you know that 24KB of RAM is available, your game can start using it. 5) Optionally you can replace the BIOS with RAM, using I/O port 7Fh. Make sure you only use the two values described above (‘00001111b’, ‘00001101b’), or your game may not work on an ADAM system. I final note about the SGM and ADAM: AFAIK, I/O port 53h isn’t used by any known ADAM device, so it should be safe to use the SGM with all ADAM expansion cards in place. However I cannot guarantee that a future (or even current) device will not use (or may be already using) that specific port, so users should make sure there is no other device in their ADAM system using port 53h. For ColecoVision users, there is no risk of conflict. 4 Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted October 9, 2012 Share Posted October 9, 2012 You should post a link to this thread in the "ColecoVision Programming" sub-forum. Quote Link to comment Share on other sites More sharing options...
youki Posted October 11, 2012 Share Posted October 11, 2012 Can we really damage physically the ADAM or the Module? I would'nt recommend SGM Owner to try non-certified (by a known publisher) ROM found on the net with for instance their AtariMax Cartridge if the module is plugged. Quote Link to comment Share on other sites More sharing options...
ten-four Posted October 11, 2012 Share Posted October 11, 2012 Hi youki. I think there is some misunderstanding here. I don't think anything happen, maybe a blank screen. It is only about 53h in programming phase. But of course nothing is 100%. Quote Link to comment Share on other sites More sharing options...
youki Posted October 12, 2012 Share Posted October 12, 2012 but he say : But before doing so, you also need to make sure the module isn’t attached to an ADAM system, otherwise there may be a memory conflict with potential for damaging the ADAM and/or the SGM. What i'm worry about, is if a bad guy could do a malware ROM that could break the module or the Adam ? Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted October 12, 2012 Share Posted October 12, 2012 What i'm worry about, is if a bad guy could do a malware ROM that could break the module or the Adam ? Wow, a guy would really have nothing to live for if he wasted his time creating malware for a 30-year-old computer that few people own and even fewer use on a regular basis. But I see your point. In a more realistic setting, there could be unintentional damage done by software that doesn't test ADAM vs SGM properly, so the dangers (if there are any) need to be clearly documented. So now, who wants to volunteer his ADAM and/or SGM for a good electronic burn? I'll provide the marshmallows. Quote Link to comment Share on other sites More sharing options...
ten-four Posted October 12, 2012 Share Posted October 12, 2012 Hi youki. That would be a serious problem. Maybe the module should be: "Only for use with ColecoVision". I can see what you mean. Quote Link to comment Share on other sites More sharing options...
youki Posted October 12, 2012 Share Posted October 12, 2012 Wow, a guy would really have nothing to live for if he wasted his time creating malware for a 30-year-old computer that few people own and even fewer use on a regular basis. But I see your point. In a more realistic setting, there could be unintentional damage done by software that doesn't test ADAM vs SGM properly, so the dangers (if there are any) need to be clearly documented. So now, who wants to volunteer his ADAM and/or SGM for a good electronic burn? I'll provide the marshmallows. Unfortunaly , you can not imagine how some people can be stupid. But i'm suprised that you can really burn the hardware just by software?... No way to avoid that by electronics? I don't know , putting some Diode somewhere to protect the chip or what ever ? I have to admit i forget all my electronics basis i learnt at school.. Quote Link to comment Share on other sites More sharing options...
+5-11under Posted October 12, 2012 Share Posted October 12, 2012 If this is just a potential memory contention issue for the Adam... It may be possible, but I've done this too many times before (not with the ADAM), and never broken any parts this way. Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted October 12, 2012 Share Posted October 12, 2012 If this is just a potential memory contention issue for the Adam... It may be possible, but I've done this too many times before (not with the ADAM), and never broken any parts this way. Right. In all seriousness, the ADAM may freeze up or even go bonkers, but actual physical damage? Not likely. Eduardo is just being extra careful because he wants to avoid any possible problem with ADAM users, and "any problem" includes minor hardware incidents. Quote Link to comment Share on other sites More sharing options...
youki Posted October 12, 2012 Share Posted October 12, 2012 Indeed, is the risk is just a freeze of the machine , and just need to restart. It is not an issue. the word "Dammage" is may be a little strong, so . Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted October 12, 2012 Share Posted October 12, 2012 Indeed, is the risk is just a freeze of the machine , and just need to restart. It is not an issue. the word "Dammage" is may be a little strong, so . Yeah, but the actual possible effects of faulty ADAM/SGM detection should still be documented. As a totally theoretical and hypothetical example, let's say you turn on your ADAM with the SGM plugged into it, you start a cartridge game which activates the SGM's RAM without checking for the ADAM's RAM, and this causes the ADAM to reset automatically, and in such a way that a portion of any digital datapack (which happens to be present in the drive at the moment of reset) gets erased! That's probably the worst thing that could realistically happen, and while it doesn't do harm to the hardware itself, it is definately something ADAM owners should be aware of before plugging a SGM in and playing an SGM-dependent game! Quote Link to comment Share on other sites More sharing options...
opcode Posted October 12, 2012 Author Share Posted October 12, 2012 The chances of something bad actually happening are near to zero, as we are talking about bus contention here. Realistically I don't think it is even going to reset. However this is something we want to avoid just in case. That is why I proposed the certification program. So far all SGM games has/is been developed by myself, or I has checked them personally. So they are all certified. If you have an ADAM and want to make sure, do not use any non-certified SGM game with your ADAM+SGM. Secondly, the chances of some random program enable the SGM RAM by mistake are also near to zero, as I used an I/O range that isn't used by any known ADAM device. 1 Quote Link to comment Share on other sites More sharing options...
opcode Posted October 12, 2012 Author Share Posted October 12, 2012 Something that I would recommend is that you check the expanded memory area (2000h-5FFFh) thoroughly before activating the SGM RAM. Try different values for each memory position, like 55h and AAh, and unless you get an error for every single position, do not activate the SGM RAM. That is what I do. Also, test for mirrored RAM in the 6000h-7FFFh range. If no mirror is found, then that is an ADAM, so do not activate the SGM RAM. Quote Link to comment Share on other sites More sharing options...
retroillucid Posted October 12, 2012 Share Posted October 12, 2012 Ok, quick question If in example, I'm creating a SGM game, then I will have to send it to you to make certified? Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted October 12, 2012 Share Posted October 12, 2012 Ok, quick question If in example, I'm creating a SGM game, then I will have to send it to you to make certified? You could do that, or you could simply use publicly certified routines in your source code. This would imply that these certified routines would have to be made available for both assembly and C language... Quote Link to comment Share on other sites More sharing options...
retroillucid Posted October 12, 2012 Share Posted October 12, 2012 You could do that, or you could simply use publicly certified routines in your source code. This would imply that these certified routines would have to be made available for both assembly and C language... Ok, I see Thanks for the clarification Quote Link to comment Share on other sites More sharing options...
opcode Posted October 12, 2012 Author Share Posted October 12, 2012 Ok, quick question If in example, I'm creating a SGM game, then I will have to send it to you to make certified? Basically I would like to see the routine you are using for SGM detection. And also make sure you don't touch the memory control again after that. As I mentioned, I will share the detection routines once beta is done, but for now you will need to come up with your own routines. Quote Link to comment Share on other sites More sharing options...
+5-11under Posted October 12, 2012 Share Posted October 12, 2012 Yeah, but the actual possible effects of faulty ADAM/SGM detection should still be documented. As a totally theoretical and hypothetical example, let's say you turn on your ADAM with the SGM plugged into it, you start a cartridge game which activates the SGM's RAM without checking for the ADAM's RAM, and this causes the ADAM to reset automatically, and in such a way that a portion of any digital datapack (which happens to be present in the drive at the moment of reset) gets erased! That's probably the worst thing that could realistically happen, and while it doesn't do harm to the hardware itself, it is definately something ADAM owners should be aware of before plugging a SGM in and playing an SGM-dependent game! It's a feature! 1 Quote Link to comment Share on other sites More sharing options...
Ransom Posted October 12, 2012 Share Posted October 12, 2012 It's a feature! Who will be the first to write an SGM program that "automatically and painlessly erases your datapacks while you wait"? Quote Link to comment Share on other sites More sharing options...
retroillucid Posted October 12, 2012 Share Posted October 12, 2012 (edited) Basically I would like to see the routine you are using for SGM detection. And also make sure you don't touch the memory control again after that. As I mentioned, I will share the detection routines once beta is done, but for now you will need to come up with your own routines. I will wait till you provide me your own routines I don't want to mess out... Edited October 12, 2012 by retroillucid Quote Link to comment Share on other sites More sharing options...
+nanochess Posted October 12, 2012 Share Posted October 12, 2012 Based on the explanation it doesn't look so complicated. I'd write different values in 2000-7fff zone maybe in increments of 64 bytes and reread them for comparison. If everything is ok, then you've an ADAM. If not then activate the SGM through port $53. Quote Link to comment Share on other sites More sharing options...
NIAD Posted October 12, 2012 Share Posted October 12, 2012 Additional instructions should be provided with games that are developed for use with the SGM + CV when the end-user also has an ADAM and plans to use said game on the ADAM. For instance: Team PixelBoy's upcoming releases of Zaxxon: The Super Game and Dragon's Lair will require the SGM be plugged in to the CV to properly work, BUT these games will work on the ADAM "without" the SGM attached. Using these two games on the ADAM with a SGM attached will probably cause the conflict that Eduardo mentioned, but the only thing that should possibly happen is a system lock-up that will be cleared by pressing the COMPUTER RESET.... not the CARTRIDGE RESET. Also, seeing as we are dealing with cartridge media that needs to be plugged in with the system off, anyone that turns their ADAM on with a DDP in the drive deserves to have that DDP corrupted. I know that is mean to say, but after all these years of Coleco and numerous others stressing not to have a DDP inserted in the drive when powering on or off the system.... DKA requires the SGM in order to properly work on the CV as well as on the ADAM. The easiest thing for an ADAM owner to do would be to test each game out without the SGM attached. If the game works, then it does not require the SGM... it uses the ADAM's memory. If the game does not work, then the SGM needs to be used with the ADAM. Quote Link to comment Share on other sites More sharing options...
+grips03 Posted October 12, 2012 Share Posted October 12, 2012 if someone has an Adam with SGM and they plug in DKA cart and DKA detects the Adam's memory, and therefore does not enable the SGM's memory, does the SGM's sound chip still work? Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted October 13, 2012 Share Posted October 13, 2012 Additional instructions should be provided with games that are developed for use with the SGM + CV when the end-user also has an ADAM and plans to use said game on the ADAM. For instance: Team PixelBoy's upcoming releases of Zaxxon: The Super Game and Dragon's Lair will require the SGM be plugged in to the CV to properly work, BUT these games will work on the ADAM "without" the SGM attached. Using these two games on the ADAM with a SGM attached will probably cause the conflict that Eduardo mentioned, but the only thing that should possibly happen is a system lock-up that will be cleared by pressing the COMPUTER RESET.... not the CARTRIDGE RESET. Actually, the SGM routines that Mystery Man coded for Dragons' Lair and Zaxxon Super Game were certified by Eduardo. I tested both games on my own ADAM with the SGM plugged in, and there was no problem whatsoever. So you can rest easy, Jim. DKA requires the SGM in order to properly work on the CV as well as on the ADAM. This is also true for King's Valley and Thexder, by the way. The easiest thing for an ADAM owner to do would be to test each game out without the SGM attached. If the game works, then it does not require the SGM... it uses the ADAM's memory. If the game does not work, then the SGM needs to be used with the ADAM. Well, that's true for the long term. But for the short term, all the upcoming releases (for this year and probably next year too) are safe for the ADAM. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.