opcode Posted November 30, 2005 Share Posted November 30, 2005 Maybe in a year or two, when RWB decide to sell the Coleco name again… Then maybe the CV fans would buy it… hmmm… 973781[/snapback] How much do you think buying the Coleco name would cost, just out of curiosity? And would that include the ColecoVision name? 973856[/snapback] I don't know... Probably a few hundred thousand dollars at most. RWB are just 3 or 4 guys, with no exact idea about what they have bought. Just look their website. That doesn't look like a website from a multi-million dollar company... Eduardo Quote Link to comment Share on other sites More sharing options...
opcode Posted November 30, 2005 Share Posted November 30, 2005 Do you think it's worthwhile though to program for the CV on a commercial basis? I mean, if you love it you love it, but I'd like to see the Atari get some hungry programmers like you, and realease some really unique games that use the old technology but are fun to play and addicting as the old stuff. 973918[/snapback] I think the Flashback shown us that retro gaming is viable. You just need to include the whole platform to reach the masses, a marriage between software and hardware. Eduardo Quote Link to comment Share on other sites More sharing options...
Brad2600 Posted November 30, 2005 Share Posted November 30, 2005 Most people don't program new games for old systems out of the notion of making a profit. Most of them do it for the love of the games. Quote Link to comment Share on other sites More sharing options...
opcode Posted November 30, 2005 Share Posted November 30, 2005 Most people don't program new games for old systems out of the notion of making a profit. Most of them do it for the love of the games. 974112[/snapback] Yeah, sure. I just wanted to point out a possible way. Still, probably the harware maker would be the only one making a real profit, not the programmers... Eduardo Quote Link to comment Share on other sites More sharing options...
Jess Ragan Posted December 1, 2005 Share Posted December 1, 2005 Saw this in the local Walgreens. The games look painfully generic. Then saw it in a fly-by-night discount store and wow, this is sad. It's like my childhood has been drained. 972416[/snapback] Just be glad you didn't play it. I tried the Head to Head TV Game, and it's a total mess. It's cheaply designed, has a terrible square directional pad, and features some of the worst, most simplistic games I've ever had the misfortune to play. It's like the designers spent 75% of their time on the Coleco logo and maybe, MAYBE 25% on the actual games. I couldn't even figure out how to play them... frantic button and D-pad pressing yielded no noticable results. The first Activision TV Games system, the ugly yellow one with the rubber directional pad, is better than this. That, of course, makes Coleco's Head to Head the WORST TV GAMES UNIT EVER CREATED. Way to go, River West Brands. The only logs floating down THIS river are the kind you can't make into toothpicks! JR Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted December 1, 2005 Share Posted December 1, 2005 How much do you think buying the Coleco name would cost, just out of curiosity? And would that include the ColecoVision name? 973856[/snapback] I don't know... Probably a few hundred thousand dollars at most. RWB are just 3 or 4 guys, with no exact idea about what they have bought. Just look their website. That doesn't look like a website from a multi-million dollar company... 974097[/snapback] Man, that's a lot of money for just 3 or 4 guys... Let's say the number was roughly 100,000US$ for both the Coleco and ColecoVision names, you'd need to find 100 people ready to pay 1,000$US each, without any guarantee as to what would be done with the name! On the other hand, imagine if it DID happen... If 100 ColecoVision fans got together to buy the name, and then developping CV games became something like open source, where technical documentation and dev kits became openly available, where Eduardo could release his Super Expansion Module internationally, under an official ColecoVision label like "Super ColecoVision"? Well, come to think of it, I guess it wouldn't make much of an impact, with the Xbox 360, PS3 and Revolution being light years ahead of the CV. However, with the current popularity of plug-and-play video games (the kind sold at Wal-Mart that look like big joysticks that you plug directly in the TV), there could be a niche market waiting for a CV-on-a-chip device shaped like a Super Controller with a SD port, where people could download new CV games for free off the internet. That'd be really neat! And with a really good official dev kit (with built-in emulator for testing purposes) and well-written PDF tutorials and reference documentation, homebrew hobbyists could create new CV games on their PC and make them available to all! (I gotta stop dreaming like this, it's not good for my blood pressure...) Quote Link to comment Share on other sites More sharing options...
opcode Posted December 1, 2005 Share Posted December 1, 2005 Just taking the chance: I was talking to Nathan today and realized that maybe I didn’t communicate well the concept behind the SEM. Well, I always thought of the SEM as a “what if” exercise. Did you watch the Star Trek episode The City on the Edge of Forever? What if the US had waited a bit more to enter the WWII? Could Hitler have won the war? The SEM is my interpretation for the “what if there wasn’t the big crash?” scenario. What would Coleco do in the years following the Atari 7800 release (or even the NES)? Considering the usual videogame lifespan of 5 years, around 1987 Coleco would be forced to release a new machine. How advanced would it be? What kind of features would it have? The SEM is my personal realization of a possible follow-up for the CV. Of course it is just pure speculation, but hopefully as good as Carl Sagan speculating about which kind of living beings would exist in Jupiter. I mean, I am basing all my design decision on others consumer devices from the time, trying to make the SEM as feasible as possible had it been released around 1987. Now, I find it hard to believe that none of the Atari guys ever tried to do something like this before... Does it mean that I am plain stupid with no clue as to what classic gaming is about? Personally I find it the most exciting challenge in my whole life… Eduardo Quote Link to comment Share on other sites More sharing options...
else Posted December 1, 2005 Share Posted December 1, 2005 I've said it before and I'll say it again. Coleco DID release an enhanced machine!!! It was called the ADAM (and it started life as the Super Game Module). Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted December 1, 2005 Share Posted December 1, 2005 I am basing all my design decision on others consumer devices from the time, trying to make the SEM as feasible as possible had it been released around 1987. Now, I find it hard to believe that none of the Atari guys ever tried to do something like this before... Does it mean that I am plain stupid with no clue as to what classic gaming is about? Personally I find it the most exciting challenge in my whole life… 974846[/snapback] Well, I have to say I'm just as intrigued as the next guy about your SEM project (glad to see your web site is partly back, BTW), but there's a basic problem which (I think) explains the divergence of opinions of the "classic homebrew programmers": Let's say your SEM project becomes a fully functional device. The next question that will inevitably come up is: Who will make games for it? Sega, with the 32X add-on for the Genesis, tried to do exactly what you're proposing with the SEM. But only a handful of games designed for the 32X were released before Sega discarded it in favor of the Saturn. In the end, the limited availability of the 32X, coupled with the low number of 32X games, made the whole 32X endeavour pointless. The case of the SEM is similar, where you'll probably be releasing all the tech docs programmers need to take advantage of this new piece of hardware, but the end result is fully predictable: A handful of homebrew authors (including you, Eduardo) will take a shot at making one or more tech demos for the SEM, there will be some attention (maybe even some hype) from the homebrew scene, perhaps a few good games will even emerge, and then the SEM will fade away as "just another interesting project... in theory". The "classic homebrew guys" prefer to make games for the "non-upgraded" base systems because these systems are already widely available, which means more players can experience the fruits of their labours. The reason why I think the CV homebrew scene is so small right now is mostly a question of tool availability (and this has little to do with the relative popularity of the Atari 2600/5200/7800 homebrew scene). Having CV tech docs available on the net is nice, but if there was a proper homebrew PC dev kit with a programming language designed specifically for the CV (a language which would be easier to learn and understand than standard C, yet would compile easely into CV machine code), packaged together with a graphic tile editor, a sub-editor for creating music and sound effects, an integrated emulator/debugger with a memory monitor that lets the programmer know exactly what's happening under the hood of the machine at runtime, and a compiler/linker that produces CV ROMs (compatible with the real CV hardware, as well as any CV emulator), then you'd give homebrew programmers, both beginners and experts, one heck of an incentive to design their own CV games in record time. And then there's the real beauty of the proposition: This proposed CV dev kit could be upgraded for the SEM, so when the SEM is released as a functional product, programmers could use the dev kit to dive into it head first! If all you offer is the SEM hardware with the specs and the plain tech docs, your SEM will only attract the attention of hardcore CV homebrew guys. Is that really what you want, Eduardo? Or would you like the SEM to become a learning tool for beginner programmers? With a good dev kit, even beginners (who usually shy away from cryptic technical documentation) could get into the act, and the SEM could achieve the same level of recognition as other similiar dev kits like Game Maker. Think about it... Quote Link to comment Share on other sites More sharing options...
opcode Posted December 1, 2005 Share Posted December 1, 2005 Hi Pixelboy, You really have some good ideas here... Devkit... Ok, ok... Well, I have a CV emulator underway (in fact I was working on it right now), complete with SEM emulation. It has a integrated debugger and memory monitor, so we are probably halfway in your wish list... I proposed a Game Basic language sometime ago (probably if you do a quick search here you could find it). Graphic and sound tools are a possibility too, since I am getting good with Visual C. Oh, here is an excerpt of my Opcode Game Basic language (thanks God I archived it): GraphLine GraphLine is a unidimensional array of graphic characters which will be horizontally presented on screen. A GraphLine array needs to be defined at creation time. It means, the array size and elements need to be declared at creation time and can’t be changed after it. The GraphLine data will be compacted at compilation time and will become ROM data. GraphBlock GraphBlock is a one-dimensional array of GraphLines which will be vertically presented on screen. A GraphBlock array size and elements need to be defined at creation time and can’t be changed after it. The GraphBlock data will be compacted at compilation time if possible and will become ROM data. Figure 1 WWWWWWW } GraphLine1 \ SSSSSSSSSSSS } GraphLine2 | GraphBlock1 (You can have as many GraphBlocks as you want. BBBBBBBBBB }GraphLine3 | HHHHHHHHH }GraphLine4 / Dim GL1as GraphLine = (W,W,W,W,W,W) ..... Dim GB1as GraphBlock = (GL1,GL2,GL3,GL4) Playfield Playfield is a bidimensional array of GraphBlocks which can be completely or partially presented on screen through a Window object. A playfield array element need to be defined at creation time and can’t be changed after it. It will become ROM only data at compilation time. Dim myPF(2,20) as playfield = (GB1,GB1,....,GB2,GB2) #this playfield will have 2 columns and 20 rows. Window Playfield are presented on screen through a Window object. For games which require scroll, usually the playfield will be larger than the visible Window. Beside that, sprites (movable objects) will always act relative to Windows objects. There can be as many Windows as desired, but usually just 1 or 2 will be necessary (a good example for 2 Windows is a head-to-head split screen game). Window dimensions are defined at creation time and can’t be changed, though it’s possible to change the associated Playfield. Functions for showing, clearing, scrolling will be available. Window uses RAM to save pointers. Screen Screens make for the final object in this chain. Screens bound Windows objects together, positioning them on TV screen. You can create as many Screens as you want, but just a Screen can be used at a time. For example, you can create a intro Screen, a selection Screen and a gameplay Screen. When creating Screens, you need to define the composing Windows and their coordinates on TV screen. Functions for selecting, showing and clearing Screen will be created. Back to the SEM topic, I think you are forgetting that the SEM also offers new possibilities for existing CV games. Besides being able to load games from the SD card, one could also edit the color palette for a given game or enter GameGenie like codes. And since I am going with FPGA, I could (and want to) release a complete system in a single board, complete with SEM built-in. Considering how cheap FPGAs are now, I believe it would be possible to have the complete system for $100 or less (probably I wouldn't include the BIOS, but it would be loaded from the SD card during the boot, so I don't need to worry about RWB). Anyway I liked your idea about the devkit. Let’s discuss it a bit more (I could start a thread in the homebrew forum). I think the SEM will offer some very nice features which are easy to use and powerful. Probably the feature I am prouder of is that the SEM video (now called CV9956) uses a bitmapped framebuffer, which is far more flexible than tiled videos. And the companion video co-processor (or blitter) will free the CPU from almost all video duties. The blitter (still need to find a cute name for it) can transfer large chunks of data very quickly, while executing logical functions over the data, like superimposing a rectangular image over the background with transparency information or adding palette information to neutral data. I chose to go with framebuffer cause it seems more the American way to do things, while tiled videos seems more like the Japanese way. And the blitter offers a kind of flexibility typical of US machines... Eduardo Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted December 1, 2005 Share Posted December 1, 2005 You really have some good ideas here... Devkit... Ok, ok... Well, I have a CV emulator underway (in fact I was working on it right now), complete with SEM emulation. It has a integrated debugger and memory monitor, so we are probably halfway in your wish list... Is that so? That's great! I proposed a Game Basic language sometime ago (probably if you do a quick search here you could find it). Graphic and sound tools are a possibility too, since I am getting good with Visual C. I had a look at your code exerpt, and it's not exactly what I had in mind, but it's somewhat close... Back to the SEM topic, I think you are forgetting that the SEM also offers new possibilities for existing CV games. Besides being able to load games from the SD card, one could also edit the color palette for a given game or enter GameGenie like codes. And since I am going with FPGA, I could (and want to) release a complete system in a single board, complete with SEM built-in. Considering how cheap FPGAs are now, I believe it would be possible to have the complete system for $100 or less (probably I wouldn't include the BIOS, but it would be loaded from the SD card during the boot, so I don't need to worry about RWB). Ah, so RWB owns the right to the CV BIOS? Didn't know that. It does complicate things, doesn't it? Anyway I liked your idea about the devkit. Let’s discuss it a bit more (I could start a thread in the homebrew forum). Please do. I'll join you soon after. I think the SEM will offer some very nice features which are easy to use and powerful. Probably the feature I am prouder of is that the SEM video (now called CV9956) uses a bitmapped framebuffer, which is far more flexible than tiled videos. And the companion video co-processor (or blitter) will free the CPU from almost all video duties. The blitter (still need to find a cute name for it) How about... "Vidblit"? can transfer large chunks of data very quickly, while executing logical functions over the data, like superimposing a rectangular image over the background with transparency information or adding palette information to neutral data. I chose to go with framebuffer cause it seems more the American way to do things, while tiled videos seems more like the Japanese way. And the blitter offers a kind of flexibility typical of US machines... One thing you need to know about me is that, while I'm a computer programmer by profession, I've never really programmed a real game before, especially not on a video game console, so terms like "bitmapped framebuffer" make me go "Huh?". But still, a quick explanation of such concepts will get me up to speed. See you on the Homebrew forum! Quote Link to comment Share on other sites More sharing options...
opcode Posted December 1, 2005 Share Posted December 1, 2005 Hi Pixelboy, I proposed a Game Basic language sometime ago (probably if you do a quick search here you could find it). Graphic and sound tools are a possibility too, since I am getting good with Visual C. I had a look at your code exerpt, and it's not exactly what I had in mind, but it's somewhat close... So please let me know that you have in mind. Ah, so RWB owns the right to the CV BIOS? Didn't know that. It does complicate things, doesn't it? Well, I am guessing they own, since they bought the Coleco name. Anyway, it isn't a problem since we can require that the user load a BIOS image to the SD card. I think the SEM will offer some very nice features which are easy to use and powerful. Probably the feature I am prouder of is that the SEM video (now called CV9956) uses a bitmapped framebuffer, which is far more flexible than tiled videos. And the companion video co-processor (or blitter) will free the CPU from almost all video duties. The blitter (still need to find a cute name for it) How about... "Vidblit"? Good, I liked it. Or maybe VideoBlitter... One thing you need to know about me is that, while I'm a computer programmer by profession, I've never really programmed a real game before, especially not on a video game console, so terms like "bitmapped framebuffer" make me go "Huh?". But still, a quick explanation of such concepts will get me up to speed. Oh, sorry! Ok, so a tiled display is just like the standard CV video (TMS9928), or almost every other Japanese console, like the NES, SMS, Genesis, SNES, etc. It defines a given number of "tiles" (usually 8x8 pixels pattern graphics), then map them on screen though a "name table". Just like the PC video in text mode. Frame buffer is more like a canvas, where you can address individual pixels (the PC SVGA modes use this kind of video). Usually memory mapping in frame buffers is linear, i.e., all the bytes which forms the first line of the image comes in sequence, then all bytes for the second line and so forth... Frame buffer was the preferred video solution with classic US arcade makers, like Atari and Williams. Frame buffer is more flexible, but takes more VRAM space and is more CPU hungry if you don't have a blitter to help you. I am estimating that the SEM videoblitter will be able to move around 60 thousand pixels per frame (or 1/60s) in Graphics 5 (the most advanced display mode), considering that the CV9956 will be running at 21MHz. This clock speed is nothing special; the NES video runs at this same clock. The key is some optimizations in memory access.... Eduardo Quote Link to comment Share on other sites More sharing options...
1980gamer Posted December 6, 2005 Share Posted December 6, 2005 Just my 2 cents on the "Language" to program in. It seems to me that the Colecovision and the TI99/4A have many similarities. Screen res 32x24 and 8x8 sprites... limited to 4 sprites per row etc. Sound seems close as well. Granted that is 2 pieces of a whole system. I learned TI extened basic as a kid 12-13 years old and found it to be very easy. Of course it is not compiled code so it was SLOW... If it could be used as a dev. language that can then be compiled? I have some ideas for games, but I am a DBA and don't do much outside of SQL scripting and some ASP and VB. The last C code I touched was around 1993. I played with BATARI basic, that is pretty cool and easy. I am not a super 2600 fan, I was in the Intellivision camp as a kid..LOL Had a TI, C64 and ColecoVision as well. My friends had 2600's I liked a few of the 2600 Activision games, but Coleco was much better for Arcade games and Intellivsion couldn't be touched for sports games. Sorry I got so far of topic. I don't post often, but when I do... Take care, Geno Quote Link to comment Share on other sites More sharing options...
opcode Posted December 7, 2005 Share Posted December 7, 2005 Hi Geno, Right, the CV and the TI99/4A shared the same video and audio processors. We started another thread in the homebrew forum. If you want to follow the Dev Kit discussion please go here: http://www.atariage.com/forums/index.php?showtopic=79992 Eduardo 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.