Jump to content
IGNORED

Super Game Module technical forum


opcode

Recommended Posts

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.

  • Like 4
Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

What i'm worry about, is if a bad guy could do a malware ROM that could break the module or the Adam ?

 

:lol: 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. :P

Link to comment
Share on other sites

:lol: 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. :P

 

 

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.. :(

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

  • Like 1
Link to comment
Share on other sites

 

 

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 by retroillucid
Link to comment
Share on other sites

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:

 

:arrow: 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.... :mad:

 

:arrow: 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.

Link to comment
Share on other sites

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:

 

:arrow: 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. ;)

 

 

:arrow: 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. :)

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...