The Official "Super Expansion Module" Thread

[gulag picture radio]

Or how about adding ethernet so I can Twitter from my Colecovision?

[+opcode]

For ethernet access we would need an ethernet controller chip, plus implementations of the TCP/IC stack, etc. Very interesting but not worth investing in this current project. We can save that for the ColecoVision2 though.

For now what could be done is to connect the SGM to a PC (thru the printer port for example), and then use the PC to access the internet. Much simplier, as neither the ethernet controller or TCP implementations are required. And of course the overhead would be minimum for the CV, not more than local Coleconet (C-net, Colecolink, C-link, I always like to think of cool names). The only problem is that you would need to keep a PC nearby (much easier if you have a laptop).

[Yurkie]

For ethernet access we would need an ethernet controller chip, plus implementations of the TCP/IC stack, etc. Very interesting but not worth investing in this current project. We can save that for the ColecoVision2 though.

For now what could be done is to connect the SGM to a PC (thru the printer port for example), and then use the PC to access the internet. Much simplier, as neither the ethernet controller or TCP implementations are required. And of course the overhead would be minimum for the CV, not more than local Coleconet (C-net, Colecolink, C-link, I always like to think of cool names). The only problem is that you would need to keep a PC nearby (much easier if you have a laptop).

 

So let me see if I understand you. I could connect the port on the module to my Laptop and play online if there was server in place? Is there a cable that plugs into the module and has a USB on the other end? The only ports I have on my laptop are 2 usb, 1 mini usb, ethernet, VGA and phone cord port (for 56k modem). What is the name for the port type on the module? Is it a parallel port? If so would this work?

 

That asked why not have a female USB port on the module? The reason I ask, is that Parallel Port cables seem to be rather expensive so it seems logical that the port on your module would be more expensive than a USB.

 

I hate even bringing up the port question since I want BETA testing to begin as soon as possible, but parallel ports are rather old technology.

[+opcode]

 

So let me see if I understand you. I could connect the port on the module to my Laptop and play online if there was server in place? Is there a cable that plugs into the module and has a USB on the other end? The only ports I have on my laptop are 2 usb, 1 mini usb, ethernet, VGA and phone cord port (for 56k modem). What is the name for the port type on the module? Is it a parallel port? If so would this work?

 

That asked why not have a female USB port on the module? The reason I ask, is that Parallel Port cables seem to be rather expensive so it seems logical that the port on your module would be more expensive than a USB.

 

I hate even bringing up the port question since I want BETA testing to begin as soon as possible, but parallel ports are rather old technology.

 

USB would require a controller, extra chip, etc. Parallel port is already there, the AY-3-8910 offers it. So for now the only way to connect is thru the PC printer port. However we could create a small adapter (for the parallel port) to include SD and USB ports if there a good reason to do so. I believe such adapter would be inexpensive, just like the paddle adapter. In fact that would be the base of the computer system, just a SD and USB ports. Such USB controllers usually already implements FAT, so that would save me a lot of work. Yeah, sounds good, so I can replace test #3 in my list with this proposed I/O adapter (the Super I/O Adapter). This way I don't need to bother creating a BASIC or anything, I just test SD card access and USB access.

[Pixelboy]

The idea is to have a very flexible game engine integrated to the BASIC compiler, and then offer macro commands so that the programmer can fill in the blanks. Macros to create title screens, complete with the menus and sub menus, macros to store graphic data and generate different screens from it, macros for music, macros for building the game screen, defining where the score area should be placed, which data should be displayed, if the screen should scroll, which parts, direction and speed. Macros to connect the joystick to a specific sprite, to animate sprites.

 

Now that would be cool. Something to think about...

If we were talking about a more advanced computer, I would totally agree with you, but with only 1K of RAM (main stack included) and a 32K ROM limit (MegaCarts aside) the ColecoVision is an ill-advised platform for implementing such a design paradigm. Too much overhead code that the end programmer has no real control over, which tends to fill up the cart ROM space, and no matter how advanced the "macros" are, there will always be things that they will not be able to do, leaving the end programmer somewhat disappointed. That's why BasicVision is shaped the way it is, so that the BV source code can be translated into assembly language "constructs" that are optimized as much as possible, all this coupled with (future) external graphic and sound editors that produce data which can be integrated into a BV project.

 

I'm not saying the "macro" system you're describing can't be done with a good amount of success, but macros tend to be rigid in their design, and as more features are added over time to meet the specific demands of users, the whole system can become clunky and hard to explain/document.

[gulag picture radio]

This is a bit OT, but since you guys know this a lot better than I do...

 

I'v got an upcoming project where I want to be able to Twitter from an unusual retro device. My plan is to get one of those ethernet adapter thingies for a Commodore 64 and just use that. There are folks doing that already, so it should be no problem to get help. It's also nicely self contained, so it's not like I"m just using the C64 for its keyboard. It's really doing the twittering.

 

I must admit I do like the idea of doing something with the COleco, though it doesn't sound as readily feasible. What about using an ADAM? I've never actally seen an ADAM in person, so I don't know what it's capable of. Would connectivity be really weird to acheive? Remembering of course that I barely know what I'm taking about...

[+opcode]

If we were talking about a more advanced computer, I would totally agree with you, but with only 1K of RAM (main stack included) and a 32K ROM limit (MegaCarts aside) the ColecoVision is an ill-advised platform for implementing such a design paradigm. Too much overhead code that the end programmer has no real control over, which tends to fill up the cart ROM space, and no matter how advanced the "macros" are, there will always be things that they will not be able to do, leaving the end programmer somewhat disappointed. That's why BasicVision is shaped the way it is, so that the BV source code can be translated into assembly language "constructs" that are optimized as much as possible, all this coupled with (future) external graphic and sound editors that produce data which can be integrated into a BV project.

 

I'm not saying the "macro" system you're describing can't be done with a good amount of success, but macros tend to be rigid in their design, and as more features are added over time to meet the specific demands of users, the whole system can become clunky and hard to explain/document.

 

Let’s get a simple example, sprite management, aka sprite driver. Do you really expect a beginner to be able of creating such a driver just because he can now use BASIC? Do you think he/she will have fun trying to create such driver? I think most people will just give up before they are halfway.

Batari BASIC is successful because it is the first and only high level language for the 2600 (and btw it masks a lot of hardware details from the user), but the ColecoVision already has C.

And I just cannot see how changing

 

for (i = 0; i < 10; i++) {}

 

to

 

 for i = 0 to 9

next i

 

or creating a highly structured BASIC dialect can make any difference to the programmer. C is very efficient and graphic and sound libraries are already available (as well as tools). So in my very humble opinion you are just reinventing the wheel. And I say that as a constructive criticism.

An easy to use language for games must offer all the building blocks already done, so the programmer can concentrate on the creative part and don’t worry about the thousands of small low level details. And if he/she wants to have more control, then they can move to C or better yet, ASM.

And the design paradigm I suggested can be done as long as you are using a PC to cross compile. In fact I believe it would be capable of producing much more advanced games, as the engine is generated by the compiler and can be optimized in a very low level depending on the features required by the game. The problem isn’t the ColecoVision’s 1KB of RAM, the tough job would be to create such compiler.

[+opcode]

This is a bit OT, but since you guys know this a lot better than I do...

 

I'v got an upcoming project where I want to be able to Twitter from an unusual retro device. My plan is to get one of those ethernet adapter thingies for a Commodore 64 and just use that. There are folks doing that already, so it should be no problem to get help. It's also nicely self contained, so it's not like I"m just using the C64 for its keyboard. It's really doing the twittering.

 

I must admit I do like the idea of doing something with the COleco, though it doesn't sound as readily feasible. What about using an ADAM? I've never actally seen an ADAM in person, so I don't know what it's capable of. Would connectivity be really weird to acheive? Remembering of course that I barely know what I'm taking about...

 

I am not sure either, I really don't keep track of what is going on in the ADAM scene. It is possible an ethernet interface exist, but better check with the ADAM people at the Coladam mailing list.

 

[email protected]

http://adamcon.org/cgi-bin/mailman/listinfo/coladam

[+opcode]

Ok, so I took a break of all things Opcode during the weekend so that I could enjoy family, Muppets and Atari 8-bit computers.

 

Now is time to get back to work. Here is the latest news:

 

Wolf_, from the Pac-Man Fever tune in PMC fame, just confirmed his participation in Donkey Kong Arcade. Again he will be creating the opening tune, but this time he has a much more powerful sound arsenal at his disposal (6 PSG channels, 2 ADPCM), and he plans to use all of it, so we can expect for some truly amazing music coming out of the CV soon.

 

In the meantime you may want to visit Wolf_'s page at Youtube:

www.youtube.com/mvsmsx

[goldenegg]

Is it too late to get on the list for one of these? Is there even a need to get on a list? I'm unclear if this will be a regular product you'll offer or if it's limited. Either way, I definitely want one :-)

 

Was selecting "Subscribe to this list if you would like to purchase the Super Game Module" when I signed up for the mailing list enough?

 

I have to say I couldn't be happier to see all the support behind the Colecovision. It was my first console (got it the day it came out) and I still play it today. Definitely looking forward to the titles being created for this expansion!!

[+opcode]

Was selecting "Subscribe to this list if you would like to purchase the Super Game Module" when I signed up for the mailing list enough?

 

Yes, that is enough. We will keep you informed.

 

Thanks for the support!

[Yurkie]

Any status updates?

[+opcode]

Ok, so after a little break, I have resumed work on the SGM. First the bad news: I assembled a quick dirty prototype for the Oki sound chip and after some testing trying to figure out why my samples weren't playing the way they were suppose to play, I found out that actually the Oki chip doesn't work the way I thought it should.

We have this 128 bytes FIFO, which I thought should be enough to 8kHz sampling rate requiring a single update each frame, but actually it is good for only half that. What happens is that once the FIFO gets half empty, the ADPCM takes that as "end of file". So the remaining bytes are played and the sound is interrupted, no matter if I fill the FIFO again. So the rule is, you cannot let the FIFO go below half, or the sound playback stops.

The consequence is that I need to load data more frequently than once every frame, which is very inconvenient.

So my 3 options are:

1) Add a timer to the design and interrupt the CPU to load data twice or more times each frame

2) Add DMA to the design, so that the DMA keeps the FIFO full

3) Take the Oki chip out of the design

 

I decided to go with option 3 for 2 reasons:

1) Options 1 and 2 would add more complexity to the module than it is worth (considering cost, board space, etc). Option 1 would increase CPU usage too much

2) ColecoVision 2 waits

 

Now the good news:

During my hiatus I decided to study 6502 assembly and by consequence I was able to analyze the Famicom/NES version of DK. With that I have the routines I needed to be able to reproduce the few analog sounds found in the arcade game. So I don't need the Oki chip for that anymore. And to be honest I don't need the Oki chip for any of the planned short term SGM games anyway.

 

So that all said, lets go ahead with what we have, I am going to produce a new version of the existing alpha board I created a few months ago and will just add a couple of improvements, like the added memory (now 32KB, versus 24Kb in the previous version) and add a couple of signals to the parallel port.

 

Eduardo

[Pixelboy]

So that all said, lets go ahead with what we have, I am going to produce a new version of the existing alpha board I created a few months ago and will just add a couple of improvements, like the added memory (now 32KB, versus 24Kb in the previous version) and add a couple of signals to the parallel port.

So there will be no sound chip at all in the SGM? Not even an MSX PSG for added sound channels?

 

Not a complaint, obviously, just wondering.

[+opcode]

So that all said, lets go ahead with what we have, I am going to produce a new version of the existing alpha board I created a few months ago and will just add a couple of improvements, like the added memory (now 32KB, versus 24Kb in the previous version) and add a couple of signals to the parallel port.

So there will be no sound chip at all in the SGM? Not even an MSX PSG for added sound channels?

 

Not a complaint, obviously, just wondering.

 

No, no, the PSG is still there. It is pretty much as before, RAM, PSG and parallel port.

My plans are to have the betas produced before I leave to Brazil in November. Then I can have beta testing done for about 3 or 4 months.

[Pixelboy]

No, no, the PSG is still there. It is pretty much as before, RAM, PSG and parallel port.

My plans are to have the betas produced before I leave to Brazil in November. Then I can have beta testing done for about 3 or 4 months.

Okay. So how will the Oki chip be integrated into the ColecoVision 2? Or more to the point, how do you perceive that it will be easier to insert the Oki in the CV2 if it's a hassle with the SGM? Again, just curious.

[+opcode]

No, no, the PSG is still there. It is pretty much as before, RAM, PSG and parallel port.

My plans are to have the betas produced before I leave to Brazil in November. Then I can have beta testing done for about 3 or 4 months.

Okay. So how will the Oki chip be integrated into the ColecoVision 2? Or more to the point, how do you perceive that it will be easier to insert the Oki in the CV2 if it's a hassle with the SGM? Again, just curious.

 

Each of these projects have different goals.

With the SGM we are looking for the smallest possible device at the lowest possible cost.

With the CV2 price and size are less of a concern. With the CV2 we can go with DMA, which is the best possible solution, though that is going to require a larger (and slightly more expensive) CPLD to implement. And I also have some other personal ambitions with the CV2 project, like producing a full-fledged computer system version.

 

Eduardo

[Yurkie]

 

.....And I also have some other personal ambitions with the CV2 project, like producing a full-fledged computer system version.

 

Eduardo

 

I doubt you will go this route, but I think the CV2 should be a portable handheld with video out and controller ports.

[128Kgames]

Without the Oki chip can sounds such as voices still be reproduced? (Or whatever the voice/sound samples are called for say Wizard of War etc.).

 

I know you touched on this stuff before Eduardo but I am pretty clueless when it comes to the Coleco hardware.

[ten-four]

Hi Eduardo

 

As you probably know and have read, that is produced an AtariMax Ultimate SD Cart.

 

If your MegaCart2 allows to store data such as high score, will the new SGM also allow it to SD Ultimate ?.

 

Would they communicate with each other ?, SD Ultimate uses the following standards: FAT 16 / FAT 32.

 

What I mind is whether it also would be able to store on SD Ultimate Cart vs. MegaCart2 ?.

 

 

Ole Nielsen.

[+GroovyBee]

[quote name='opcode' date='Thu Jul 15, 2010 2:53 AM' timestamp='1279158792' post='2051157'

We have this 128 bytes FIFO, which I thought should be enough to 8kHz sampling rate requiring a single update each frame, but actually it is good for only half that.

 

At 60Hz you'd need to stuff 134 bytes into the FIFO to keep it topped up for 8kHz playback. For PAL it would be 160.

[+opcode]

Hi Eduardo

 

As you probably know and have read, that is produced an AtariMax Ultimate SD Cart.

 

If your MegaCart2 allows to store data such as high score, will the new SGM also allow it to SD Ultimate ?.

 

That is up to Steve. I have no association with SD Ultimate, so I have no idea.

 

Would they communicate with each other ?, SD Ultimate uses the following standards: FAT 16 / FAT 32.

 

They who? MC2 with SD Ultimate? Again, I think it is totally up to Steve.

 

What I mind is whether it also would be able to store on SD Ultimate Cart vs. MegaCart2 ?.

 

 

As I understand it, SD Ultimate needs a ROM image. No ROM image, no game. I think that pretty much answers your question.

 

From my perpective SD Ultimate and SGM/MC2 are totally unrelated projects.

[+opcode]

Ok, so I have the PLD logic done for the SGM version 1.1.

New to this version is:

- Now I can use full 32KB of RAM. The extra 8KB comes from optionally disabling the BIOS

- Now I have control over the spinner IRQ generation. No big deal but necessary because the parallel port now offers IRQ input

- Most important of all, the SGM is now ADAM compatible (finally)

 

Now to the new PCB...

[+opcode]

With DKA mostly done, it is time to get back to the Super Game Module.

As some of you may remember, last year I managed to produce a fully functional prototype, which was small and cheap to produce, still included the basic features I wanted the SGM to have. It was also well designed and built (IMHO). However...

 

I have decided to make that plan B...

 

The SGM has seen quite a number of different possible implementations, but in the end I am never 100% happy with any of them. A couple of years ago I planned to use FPGAs to do stuff that wasn't available off-the-shelf, but then I changed my mind because I thought it was too complicated to design for SMD parts, I wanted everything to stay in the good old “thru hole” realm.

 

However last year's version of the SGM proved I could work comfortably with SMD stuff, as well as with programmable logic. So I decided to give FPGAs another shot (I already have the development kits anyway).

 

The thing I am most unhappy with in the current design is the improved sound. Pixelboy can probably attest how psyched I am about sound. And the PSG I am currently using, while an improvement over the stock CV PSG, is still a very modest one. And then I wanted to have some sort of PCM playback capability for voice and stuff, still the only solution I could find, an ADPCM chip from Oki, seems to be too much of a burden for poor old Z80. FM is just a pain to deal with, and not very good for certain uses, even though I like the sound of it a lot. Then we have the SCC, the sound chip Konami created for the MSX that sounds wonderful and is a blast to program for, but is no longer available.

 

So what I plan to do is to create my own sound solution for the SGM, which would cover the most areas for my specific needs. It isn’t secret that I am mostly interested on arcade ports, so FM isn't that interesting for me as it is more of a late 80s thing. On the other hand PSG is a little too limited. The best option is wavetable, like the SCC.

 

With wavetable we can have for once perfect emulation of the sound chip Namco used in their classic arcades, we can have PSG emulation (square wave), we can have SCC emulation (in case we decide to port some of the final and best Konami games for the MSX). We can even have very accurate NES sound emulation.

But best of all we can have playback of voices and sound FX that were original created by discrete circuits in the original arcades, and those would be otherwise near to impossible to properly reproduce using a regular PSG. And better yet, with almost zero use of precious CPU time.

 

So I already have a design for this new chip and I am about to start working on that.

First step is to get it running on my dev kit, then eventually connect the dev kit to the ColecoVision. Once everything is running ok, I can design a board. This new board shouldn't be much different in terms of size when compared to the exiting board, as the FPGA will replace the CPLD and PSG in the existing board.

 

So I will give myself a few months to see if I can make any progress with this thing. In case I get stuck, I can just go back to plan B. On the other hand if I succeed...

 

More details soon...

[Pixelboy]

But best of all we can have playback of voices and sound FX that were original created by discrete circuits in the original arcades, and those would be otherwise near to impossible to properly reproduce using a regular PSG. And better yet, with almost zero use of precious CPU time.

CHICKEN! FIGHT LIKE A ROBOT!

 

Huh, sorry, that came out of nowhere...

 

 

So I already have a design for this new chip and I am about to start working on that.

First step is to get it running on my dev kit, then eventually connect the dev kit to the ColecoVision. Once everything is running ok, I can design a board. This new board shouldn't be much different in terms of size when compared to the exiting board, as the FPGA will replace the CPLD and PSG in the existing board.

Sounds promissing. (Pun intended.)

 

By the way, have you ever seen the ADAM Auto-Dialer expansion module? If you could make the SGM PCB small enough, you could actually use the auto-dialer's plastic casing, with some very minor modifications. Just a thought...