896 replies to this topic

[ACrystal2011]

Rather get it late and have it perfected

[opcode]

Ok, I have rev B done. I made a few adjustments. Screw holes weren't perfect, now they should be. Tweaked edge connector drill sizes. For some reason they were too tight. Strange that I don't remember having a problem with the previous version. Better of all, both PSGs (CV and SGM) have now in perfect volume balance.

However.... I am also finishing rev C. Rev C includes a D sub 9 connector (female) connected to the PSG I/O ports. It has 6 input pins, 1 output pin, 5V and GND. That is all I need to implement whatever special controllers I may want.

Actually it is all part of a plan, I need a special controller for Arkanoid. The SAC spinner isn't good, and it isn't smooth (fact is, the SAC sucks). However creating a special controller would be a very expensive proposition (because of the case). My plan is to develop a controller plastic case that can be used by several different controllers and so recoup the necessary investiment. So I plan a special arcade joystick that I can sell for different consoles, simply by changing the PCB. The SGM version would feature a realistic arcade configuration, with 1P and 2P start, coin insert and auto-fire control. The same case can then be used for the Arkanoid spinner. Just like an arcade controller I can have some logic inside taking care of movement detection and I get a screen coordinate when I read it. So no CPU being wasted by tricky controller quadrature.

In case I decide to go with rev C, all SGM games will support the arcade controller, even before it is released.

Edited by opcode, Fri Mar 30, 2012 7:45 AM.

[Ransom]

That sounds fantastic!

[Pixelboy]

opcode, on Fri Mar 30, 2012 7:38 AM, said:

So I plan a special arcade joystick that I can sell for different consoles, simply by changing the PCB. The SGM version would feature a realistic arcade configuration, with 1P and 2P start, coin insert and auto-fire control. The same case can then be used for the Arkanoid spinner.

I'm not sure I'm following... Would your "SGM version" still plug into the front expansion port? If yes, then the controller would be equiped with two wires: One with a 60-pin edge connector for the expansion port, and the other would be a DB9 to be plugged in joystick port #1?

[opcode]

No no, I am working on a rev C PCB that includes a D sub 9 plug. The same as the Atari, but female, just to make sure nobody tries to plug a ColecoVision controller there. Since the controller port on the SGM is, let's say, more complete than the ColecoVision standard port, that would allow me to create the kind of controllers not possible using the CV standard port. And since that is a brand new port, I don't need to follow standards, like including keypads and such. I can custom create whatever I want. Of course I am putting that port there primarily because of Arkanoid, Pole Position and such, which require a good spinner. But if I am going to invest on a spinner, create a plastic case for it and such, why not use the same case for different controllers. You see, if I create a case only for the spinner, the controller alone would cost three times or more the price of the game, which is insane. However, if I can design a case flexible enough to allow me to produce joystick controllers, than we are talking about possibly hundreds of units and the price goes down considerably. That is what I plan to do. Of course all SGM games that doesn't require a spinner can be played with regular CV controllers, but I am also going to support the "SGM controller port" from day one, so whenever the SGM joystick is release, it should work with all SGM games.

I could write pages about why I want to do this. I tried to figure out a way to build a good spinner using the standard CV port, but I couldn't think of anything really good. The lack of 5V in the joystick port hurts.
Also, the keypad was nice back then and such (mostly because the Intellivision had one), but it's mostly useless. Even worse, it is a pain to produce new CV controllers because of that. You can create that nice tabletop arcade controller and then you are going to need to put an ugly phone keypad on it (because of course no one is going to produce a custom keypad to match the controller look). And if you say screw the keypad, well, your controller wouldn't be fully compatible. Then you can create a pass thru port and have a CV joystick attached to your nice looking arcade controller like a kind of bizzare Wii Nunchuk (and at least the Wii Nunchuk matches the Wii remote design). So no matter what, it isn't going to look good.

So a brand new controller with a joystick, 2 or 4 buttons (2 should be enough), 1P, 2P, credit insert, pause and service mode, should be more than enough. Then add programmable auto-fire and fire button configuration and we should have a great arcade controller.

[Pixelboy]

opcode, on Fri Mar 30, 2012 9:29 AM, said:

No no, I am working on a rev C PCB that includes a D sub 9 plug. The same as the Atari, but female, just to make sure nobody tries to plug a ColecoVision controller there. Since the controller port on the SGM is, let's say, more complete than the ColecoVision standard port, that would allow me to create the kind of controllers not possible using the CV standard port. And since that is a brand new port, I don't need to follow standards, like including keypads and such. I can custom create whatever I want. Of course I am putting that port there primarily because of Arkanoid, Pole Position and such, which require a good spinner. But if I am going to invest on a spinner, create a plastic case for it and such, why not use the same case for different controllers. You see, if I create a case only for the spinner, the controller alone would cost three times or more the price of the game, which is insane. However, if I can design a case flexible enough to allow me to produce joystick controllers, than we are talking about possibly hundreds of units and the price goes down considerably. That is what I plan to do. Of course all SGM games that doesn't require a spinner can be played with regular CV controllers, but I am also going to support the "SGM controller port" from day one, so whenever the SGM joystick is release, it should work with all SGM games.

Ah, okay, I get it now.  

By the way, how many "pins" does a regular telephone cable connector have? If there are enough pins, perhaps you could use a telephone (or LAN) cable, which would be easely replaceable if it breaks. And then you could just tell your "plastic casing guy" to put one of the old holes back in the AutoDialer casing.    But then again, can you run a 5V line through a telephone cable? I'm no expertiser with those things.  

Quote

So a brand new controller with a joystick, 2 or 4 buttons (2 should be enough), 1P, 2P, credit insert, pause and service mode, should be more than enough. Then add programmable auto-fire and fire button configuration and we should have a great arcade controller.

I'll want to show you something during my upcoming visit.  

[opcode]

Pixelboy, on Fri Mar 30, 2012 9:55 AM, said:

By the way, how many "pins" does a regular telephone cable connector have? If there are enough pins, perhaps you could use a telephone (or LAN) cable, which would be easely replaceable if it breaks. And then you could just tell your "plastic casing guy" to put one of the old holes back in the AutoDialer casing.    But then again, can you run a 5V line through a telephone cable? I'm no expertiser with those things.  

Not a bad idea actually. RJ45 would be a good option for its compact connector size and easy to find cable.

[opcode]

Order for Rev B placed. I hope to have it assembled and tested before I leave to Brazil.

[ten-four]

opcode, on Fri Mar 30, 2012 9:29 AM, said:

So a brand new controller with a joystick, 2 or 4 buttons (2 should be enough), 1P, 2P, credit insert, pause and service mode, should be more than enough.
Then add programmable auto-fire and fire button configuration and we should have a great arcade controller.

That sounds great , but there will be no more Pac-Man Plus with your new OpCode controller.

[Pixelboy]

ten-four, on Mon Apr 2, 2012 7:29 AM, said:

opcode, on Fri Mar 30, 2012 9:29 AM, said:

So a brand new controller with a joystick, 2 or 4 buttons (2 should be enough), 1P, 2P, credit insert, pause and service mode, should be more than enough.
Then add programmable auto-fire and fire button configuration and we should have a great arcade controller.

That sounds great , but there will be no more Pac-Man Plus with your new OpCode controller.

Pac-Man Collection is programmed to accept inputs from the standard controller ports. It will not be compatible with any controller plugged into the SGM's special port. Only new games will be able to take advantage of the SGM's new controller port.

[opcode]

Well, I tried, but at this point I would say that the "regular" SGM won't be compatible with the ADAM after all. I don't want to go too technical, but the problem is a line in the expansion port that is responsible for disabling the CV memory decoder. I need that, and the ADAM memory controller is already using that (by driving the line). As I understand Coleco had no plans to further expand the ColecoVision memory beyond the ADAM maximum 128KB. So even though the line is still present in the ADAM expansion port, it cannot be reliably used anymore.
So at this point I have decided to have two different versions of the SGM, the regular black for the ColecoVision only, and a beige version for the ADAM only (in case there is demand for that). I apologize for that, but there isn't much I can do.

Edited by opcode, Mon Apr 2, 2012 11:13 AM.

[retroillucid]

Then, count me in for both CV and ADAM version  

[Pixelboy]

opcode, on Mon Apr 2, 2012 11:12 AM, said:

So at this point I have decided to have two different versions of the SGM, the regular black for the ColecoVision only, and a beige version for the ADAM only (in case there is demand for that). I apologize for that, but there isn't much I can do.

I just want to make sure I'm getting this correctly: Will the beige edition be compatible with both the Expansion Module #3 and stand-alone ADAM? So you'll have two active versions of the SGM's PCB?

[NIAD]

opcode, on Mon Apr 2, 2012 11:12 AM, said:

So at this point I have decided to have two different versions of the SGM, the regular black for the ColecoVision only, and a beige version for the ADAM only (in case there is demand for that). I apologize for that, but there isn't much I can do.

Seeing as I was planning to get two SGMs anyway, this more than justifies/cements it for me. If you have enough interest for the ADAM only (beige) version of the SGM, I'll take one and then one black SGM for the CV only.

I'm thinking NO will be your answer, but will the ADAM (beige) version of the SGM be compatible with the ColecoVision?

Indeed, Coleco did not plan to expand the memory of the ADAM Computer any further than an additional 64K on top of the 64K (not 80K as Coleco advertised... little slight of hand by them there) that was included in the system. In order for hardware homebrewers to get 128K, 256K, 512K, 768K and 1Mb Memory Expanders to be properly addressed on the ADAM, a Parallel Interface card with Memory Addressor (or if the person didn't need a Parallel Interface, they could buy just a Memory Addressor Card) capabilities needed to be installed in Expansion Slot #2 and a jumper wire from the Memory Expander in Slot #3 attached to it.

Pixelboy... if you are using an Expansion Module #3 ADAM Computer OR Stand-Alone ADAM Computer, then I'm pretty confident that you will need the ADAM (beige) version of the SGM. Will have to wait for Opcode to verify, however.

Edited by NIAD, Mon Apr 2, 2012 4:12 PM.

[Pixelboy]

NIAD, on Mon Apr 2, 2012 4:05 PM, said:

Pixelboy... if you are using an Expansion Module #3 ADAM Computer OR Stand-Alone ADAM Computer, then I'm pretty confident that you will need the ADAM (beige) version of the SGM. Will have to wait for Opcode to verify, however.

Well, yeah, I figured that much. But what I'm not clear on is what exactly did Eduardo do to make the beige version work on the ADAM. Is the ADAM's RAM used instead of the SGM's onboard RAM chip?

[NIAD]

Pixelboy, on Mon Apr 2, 2012 5:05 PM, said:

NIAD, on Mon Apr 2, 2012 4:05 PM, said:

Pixelboy... if you are using an Expansion Module #3 ADAM Computer OR Stand-Alone ADAM Computer, then I'm pretty confident that you will need the ADAM (beige) version of the SGM. Will have to wait for Opcode to verify, however.

Well, yeah, I figured that much. But what I'm not clear on is what exactly did Eduardo do to make the beige version work on the ADAM. Is the ADAM's RAM used instead of the SGM's onboard RAM chip?

If that's the case, then the ADAM SGM should be a little bit cheaper!

[5-11under]

NIAD, on Mon Apr 2, 2012 5:08 PM, said:

Pixelboy, on Mon Apr 2, 2012 5:05 PM, said:

NIAD, on Mon Apr 2, 2012 4:05 PM, said:

Pixelboy... if you are using an Expansion Module #3 ADAM Computer OR Stand-Alone ADAM Computer, then I'm pretty confident that you will need the ADAM (beige) version of the SGM. Will have to wait for Opcode to verify, however.

Well, yeah, I figured that much. But what I'm not clear on is what exactly did Eduardo do to make the beige version work on the ADAM. Is the ADAM's RAM used instead of the SGM's onboard RAM chip?

If that's the case, then the ADAM SGM should be a little bit cheaper!

$1.50 maybe?

[opcode]

NIAD, on Mon Apr 2, 2012 4:05 PM, said:

opcode, on Mon Apr 2, 2012 11:12 AM, said:

So at this point I have decided to have two different versions of the SGM, the regular black for the ColecoVision only, and a beige version for the ADAM only (in case there is demand for that). I apologize for that, but there isn't much I can do.

Seeing as I was planning to get two SGMs anyway, this more than justifies/cements it for me. If you have enough interest for the ADAM only (beige) version of the SGM, I'll take one and then one black SGM for the CV only.

I'm thinking NO will be your answer, but will the ADAM (beige) version of the SGM be compatible with the ColecoVision?

Indeed, Coleco did not plan to expand the memory of the ADAM Computer any further than an additional 64K on top of the 64K (not 80K as Coleco advertised... little slight of hand by them there) that was included in the system. In order for hardware homebrewers to get 128K, 256K, 512K, 768K and 1Mb Memory Expanders to be properly addressed on the ADAM, a Parallel Interface card with Memory Addressor (or if the person didn't need a Parallel Interface, they could buy just a Memory Addressor Card) capabilities needed to be installed in Expansion Slot #2 and a jumper wire from the Memory Expander in Slot #3 attached to it.

Pixelboy... if you are using an Expansion Module #3 ADAM Computer OR Stand-Alone ADAM Computer, then I'm pretty confident that you will need the ADAM (beige) version of the SGM. Will have to wait for Opcode to verify, however.

In order to be able to add more RAM I must be able to disable the CV memory decoder. That means driving one of the expansion port lines. However the ADAM is already driving that line to adds its own memory. You cannot have two outputs driving the same line, unless they are both open collectors, which isn't the case with the ADAM memory controller (at least nothing is mentioned in the ADAM documentation).
So the only reliable solution I see is to have different versions of the SGM PCB, with the memory stuff removed from the ADAM version. So I thought of ordering two case colors, just to make clear which version of the SGM you are using.

The CV version (black) should never be used with the ADAM, be it stand alone or EM #3. The beige version (ADAM) can be safely plugged in on both, however it isn't going to work on a CV since it lacks the extra memory.

Hope that makes things clearer. It isn't a plot to sell more SGMs, it is just that it isn't technically feasible.

[Pixelboy]

opcode, on Mon Apr 2, 2012 6:20 PM, said:

So the only reliable solution I see is to have different versions of the SGM PCB, with the memory stuff removed from the ADAM version.

Ah! So you are using the ADAM's RAM in the beige SGM model. That answers my question.  

[opcode]

Yes, I thought of disabling the SGM RAM by default and enabling it by software after checking that no RAM was present. That would prevent bus contention by the RAMs, but stil wouldn't be enough. We would still have contention in the CV_memory_decoder_disable line.

[evg2000]

opcode, on Mon Apr 2, 2012 7:19 PM, said:

Yes, I thought of disabling the SGM RAM by default and enabling it by software after checking that no RAM was present. That would prevent bus contention by the RAMs, but stil wouldn't be enough. We would still have contention in the CV_memory_decoder_disable line.

Any way to have a switch to turn on/off?  Or if you had the memory turned on and plugged it into the adam you would cause damage?

[opcode]

evg2000, on Mon Apr 2, 2012 7:24 PM, said:

opcode, on Mon Apr 2, 2012 7:19 PM, said:

Yes, I thought of disabling the SGM RAM by default and enabling it by software after checking that no RAM was present. That would prevent bus contention by the RAMs, but stil wouldn't be enough. We would still have contention in the CV_memory_decoder_disable line.

Any way to have a switch to turn on/off?  Or if you had the memory turned on and plugged it into the adam you would cause damage?

Placing a switch on both the RAM_enable and CV_mem_decoder_disable lines would work. However if the user turn the switch on by mistake and plug the SGM into an ADAM, that may cause damage to memories or something else.

I think it is too risky. Some may say that having two different colors can't guarantee that someone isn't going to plug the black version on an ADAM. That is true, but at least we can place a warning label in the case about that. It is less probable that someone is going to plug the black version on an ADAM by mistake if there is a warning label like "NEVER EVER USE WITH AN ADAM" than, let's say, use a black module with a switch on a CV then forget to turn the switch off and plug it on an ADAM.

Edited by opcode, Mon Apr 2, 2012 7:44 PM.

[evg2000]

opcode, on Mon Apr 2, 2012 7:33 PM, said:

evg2000, on Mon Apr 2, 2012 7:24 PM, said:

opcode, on Mon Apr 2, 2012 7:19 PM, said:

Yes, I thought of disabling the SGM RAM by default and enabling it by software after checking that no RAM was present. That would prevent bus contention by the RAMs, but stil wouldn't be enough. We would still have contention in the CV_memory_decoder_disable line.

Any way to have a switch to turn on/off?  Or if you had the memory turned on and plugged it into the adam you would cause damage?

Placing a switch on both the RAM_enable and CV_mem_decoder_disable lines would work. However if the user turn the switch on by mistake and plug the SGM into an ADAM, that may cause damage to memories or something else.

Don't shoot me, as I'm not electronically inclined (though I wish I was).  Is their a way on start up to test for memory, and if not present enable SGM on board memory, otherwise leave it disabled?  Or put and optical sensor to test for black or beige?   Yeah I know the add on adam would still be the CV which is black.

[opcode]

You just gave me an idea.... Nothing like the non electronically inclined to think out of the box...

[opcode]

I can split the memory_enable line (that is also used to disable the CV_mem_decoder) into "memory_enable" and "CV_mem_decoder_disable" lines. I already have a register in the SGM to enable RAM. By default it comes disabled after power on or reset. In that case memory_enable will output "1" (it is active high) and CV_mem_decoder_disable will be placed in high impedance. That way we don't get contention on any line. Then it is up to the software to check for RAM, and if none is found, enable the SGM RAM. In that case the CV_mem_decoder_disable line would be placed out of high impedance state.

The only risk in this case is if the software enable the RAM by mistake.

Anyways, brilliant, evg2000.