Pixelboy

Get an original ColecoVision power supply, it will be a lot less of a hassle. You can find some on eBay easely, or from eColeco.com, or maybe from doubledown (VikingVideoGames.com). As stated above, the controllers are problematic, but they can be refurbished. The power switch is one of the cheapest components of the console and can be the root of problems like garbled graphics. The cartridge port can also be problematic, but personally, I've been lucky in that respect, as I haven't experienced many problems with that so far. Hopefully you won't either.

Actually, Opcode's version wasn't completely made from scratch. There's a good portion of it that was lifted directly from the arcade ROM (which is also Z80-based, like the CV), to achieve maximum authenticity.

You bring up valid points, but still, I don't see the next crash happening with this new console generation. I foresee a shift in dominance, where Sony isn't the giant that it used to be, Microsoft taking a bigger piece of the pie, and Nintendo still playing catch-up in terms of sales and business strategy (will third-party developers/publisher commit to the Wii or will Nintendo's new console lose steam fast like the Game Cube did? Time will tell, but it's really up to third-parties themselves to decide.) One secondary, yet important issue to consider are the handheld machines, namely the DS and the PSP. They offer some alternate gaming avenues when there's nothing interesting on the radar for the current home consoles. This creates a certain variety in gaming platforms, which help to maintain consumer interest. This variety did not exist back in 1984, and even worse, companies like Atari didn't quite understand the value of upgrading hardware back then. Today, the gaming industry and the media in general are much more mature. They have to be, since the consumers of today (of all ages) are so much more sophisticated in terms of what they expect out of the games they buy. I'd say the next crash will happen when a combination of these factors occur: 1) One of the major players drops out of the console business (Sony, Nintendo or Microsoft) 2) A general apathy about new games sets into the heart of consumers (more so than what we see now) 3) Some important third-party companies go bankrupt (Capcom or Konami going bankrupt would send negative waves across the entire industry). 4) Major retail outlets lose interest in devoting their valuable shelf space to new video games. #1, #2 and #4 occured in combination in 1984, which led to the crash. It might happen again in the future.

There are a couple of possibilities: 1) I could sell them to other CV homebrew programmers here in Quebec if there's a sudden demand for some. I know Daniel Bienvenu himself placed an order to Eduardo, so there won't be a shortage in the short term, but my stash of cart shells might come in handy later. I won't sell them at outrageous prices, I'll just try to get my investment back. 2) I'm planning to learn ColecoVision assembly programming in 2007, and once my first real game is done, I'll need those cart shells for myself. In any case, it's certainly not a bad investment, even though I don't need cart shells immediately.

I did (even before your post on this board), and just today, Mathieu told me he still needs to clean up the cart shells and make some cart labels. He told me he was still a few weeks away from being able to ship this new batch. Still, it doesn't hurt to pre-order. If not by you, then by who? AtariAge? GoodDealGames? GameConsoles? Is the box included, or is it cart only? Details, Daniel, we want details!!

You know, I think I'll buy a 100, for my future personal use. Expect me to mention it when I reply to your next e-mail. BTW, a quick question that just occured to me: Do standard CV PCBs (like the ones sold by AtariAge) fit inside Parker Brothers CV cart shells? I don't own any P.B. carts, so I can't unscrew one and see for myself. I'm hoping someone else can answer this question for me...

I'd be interested in knowing their prices, just out of curiosity... They're in Austin TX? Doesn't Albert do business with them?

Have you talked to opcode about it? Seing as he was able to make his CV boxes in Brazil, perhaps he can hook you up with the printer company he does business with. Or maybe not. It's just a thought anyway...

Don't forget the eBay factor. For example, I see ColecoVision consoles put under auction every day of the week on eBay. What you're less likely to find in the wild, you're more likely to find online.

Yep, now you're getting it. Yeah, I guess you could look at it that way... I think... It's simpler to say that each line in a tile can have two colors. And that's for graphic mode #2; don't get me started on graphic mode #1, which is far more restrictive! If I'm understanding your example correctly, it still would not work, because you're still using 'Y', "R' and transparent colors on your last tile (on rows 3,4,5 and 6). Separating the tiles shows your error: RRRRRRRR-RRRRRRRR RRRRRRRR-RRRRRRRR-R YYYYYYYY-YYYYYYYY-YYRR YYYYYYYY-YYYYYYYY-YYRRR YYYYYYYY-YYYYYYYY-YYRRR YYYYYYYY-YYYYYYYY-YYRRR RRRRRRRR-RRRRRRRR-RR RRRRRRRR-RRRRRRRR-R The proper way to do it would be: RRRRRRRR-RRRRRRRR-OOOOOOOO RRRRRRRR-RRRRRRRR-ROOOOOOO YYYYYYYY-YYYYYYYR-RROOOOOO YYYYYYYY-YYYYYYYY-RRROOOOO YYYYYYYY-YYYYYYYY-RRROOOOO YYYYYYYY-YYYYYYYR-RROOOOOO RRRRRRRR-RRRRRRRR-ROOOOOOO RRRRRRRR-RRRRRRRR-OOOOOOOO Where "O" is the "background color", as you would say.

Yep, that could be done. As I stated before, the transparent color is only applicable to sprites, not background tiles. If you consider black (or blue for sky color) as a "screen color", that's just how your mind perceives it. In reality, there is no such thing as a "screen color" on the CV. The screen is 32x24 tiles, which equates to 256x192 pixels. There's no way to have an 8x8 space with no tile in it, the CV doesn't work that way. About sprites, you can set the CV to display 8x8 sprites or 16x16 sprites, but not both as the same time. Furthermore, you can only use two colors for the ENTIRE sprite (no "per scanline" stuff here), and one of these colors can be the transparent color (or not). You're making the basic mistake that most beginners make when they start working with CV graphics: You're using more colors than you are allowed! In your example above, you're actually using three colors, namely "R", "Y" and the "invisible" color which you are not representing in your tile diagram. Again, there is no such thing as a "screen color" on the CV. You only have two colors (per scanline, per tile) to work with, and that's it.

If a solution is found, count me among those who will buy one of those nice power supplies. I may even buy two or three! EDIT: There's one issue you need to keep in mind: If you're planning to use a 9-pin female connector to connect the new PS to the ADAM Memory Console, such a standard 9-pin connector will not fit in the Memory Console without some force applied. Either a piece of plastic on the Memory Console's casing will need to be removed above the port, or the plastic (or metal) casing around the female connector will need to be stripped away. Just one of those nagging details...

I'm not sure I'm following your example, but allow me to try to explain it my way: In graphic mode #2, you could define an 8x8 tile like this: 00011000 --- 1=white, 0=transparent (black) 01100110 --- 1=medium blue, 0=black (non-transparent) 11110011 --- 1=dark red, 0=white 00110001 --- 1=light yellow, 0=dark red 00000000 --- 1=grey, 0=light green (this entire line is light green) 11111111 --- 1=grey, 0=light green (this entire line is grey) 10000001 --- 1=magenta, 0=black 00111100 --- 1=white, 0=black (non-transparent) So for each line inside an 8x8 tile, you can assign a color to the 1s and another color to the 0s. You've got 16 colors to choose from (color #0 is transparent, but if you use it in a tile, it comes out black, like color #1, because transparency can only be applied to sprites, AFAIK). Hope this clarifies your understanding.

Look closely at Mr Do's Castle's graphics on the CV, and you'll notice that there's never more than 2 colors per scanline, per tile. The programmers just coped with the graphical limitations of the CV and did a great job with it. Also, there's no such thing as "lower resolution" on the CV. All screen modes are 256x192 pixels, and all background tiles are always 8x8 pixels. EDIT: Sorry, that's not quite correct: There is another lower resolution mode available on the CV, which uses "big pixels" that equate to 4x4 pixels, and each of these "big pixels" has its own independent color. It's used by "Smurf Paint & Play Workshop" and also "Cabbage Patch Kid Picture Show". As you can guess, that mode is useless for anything else than basic paint programs, although I imagine someone could make a decent version of Tetris with it...

There are two distinct sides to the issue, namely owning hardware and playing games on said hardware. I can't imagine myself owning old consoles twenty years from now, because they take up space and will likely break even more than they do now (yes, I'm looking at you, ColecoVision). On the other hand, I can still play any game of just about any system (including arcade) via emulation, so if knowledgeable programmers still make emulators for the super PCs that we will have in our homes twenty years from now, I'm quite likely to revisit Donkey Kong, Mega Man, Zelda, or maybe games that won't require good reflexes, like turn-based RPGs (Final Fantasy, Phantasy Star, etc). Those are the games that stay in our hearts, even though the consoles they were made for are long gone commercially. Twenty+ years from now, when our collective hair starts turning gray, we'll still try to recapture our youth by playing the games we played when we were kids. We'll play in short bursts, but we'll play. I know I will anyway.

Yeah, I vaguely remember the game you're talking about. I checked out MAWS and the closest one I found was Munch Mobile, but I'm pretty sure that's not it. I didn't check MAWS thoroughly however, so you might want to check yourself with "Driving" as the "genre" search parameter... Maybe it's not emulated yet under MAME, but I'd be surprised if it's not.

Incompetent management is indeed largely part of the answer, but there are other factors: 1) The Adam's final design was the result of the combined effort of a large number of people - who were not all concentrated in the same geographical location - and this design had to be finalized in a very short period of time. Any experienced business manager will tell you that this is a recipee for disaster, especially when the decision-makers let the technical people do what they want with no coherent vision (other than simple directives like making it compatible with the CV console, and keeping the manufacturing costs down). Coleco's engineers spent far too little time on the overall design, and had no real idea of what audience the Adam was supposed to cater to, so they ended up doing a jack-of-all-trades-but-master-of-none system. Meanwhile, the people in marketing just waited for the Adam to be finalized, and they figured they would just do the best marketing campaign they could do with whatever the tech guys would come up with. It is this lack of coherent vision that is at the root of what the Adam ended up being: A bulky modular system that wasn't really modular at all. 2) Coleco realized way too late that they didn't know what they were doing in the home computer business. They had this old "IBM" way of thinking, where third-party software was seen as an unnecessary evil which had to be controlled by limiting access to the technical documentation of the machine. At the same time, Coleco just didn't have the resources to support the Adam with interesting first-party software: Do you know many people who actually bought and used Recipee Filer? Like several other Adam titles, it was condemned to remain shelfware as soon as it appeared in stores, while the Super Games made far more business sense. So again, as much for software as for hardware, lack of coherent vision made the Adam an irrelevant player in home computing, which more successful companies like Commodore and Atari mostly ignored. Most people's fond memories of the Adam are based on two of its components: The expandable Z80-based core (inside the memory console) and the keyboard. Anyone could see that the Adam had a lot of potential at the software level, especially when the system was upgraded with more RAM, and it is that unfulfilled potential that sparked the birth of the Adam user community that still exists today. Coleco was instrumental in teaching other companies what NOT to do when marketing a home computer. It just goes to show how pioneers can make tremendous mistakes, and eventually die because of them, while others strive by avoiding serious pitfalls.

I think it's inevitable that someday within the next few years, someone out there is going to do a better version of DK on the 2600. Like several others, I consider it one of the great homebrew holy grails, even though I'm more into the ColecoVision than the Atari 2600. johnnywc almost got into it earlier this year, but it wasn't to be. Still, I like to believe it's going to get done eventually. There are a few obstacles to acknowledge about making an improved 2600 DK. First and foremost, Coleco's offering might be the worst-looking of the home conversions of the game, but it still plays well enough to be fun, and considering the strict limitations of the hardware, it's still a very good effort. johnnywc himself said that if he was to do a better version, it would probably be a hack of the original ROM. The problem in that is that many homebrew programmers will think about it and won't see much room for improvement, so they won't embark on the endeavour. Secondly, to do an improved version of DK necessarily implies that it should be closer to the arcade version, and that's a huge challenge any way you look at it. You're looking at months and months of work, on a console that isn't well-suited for platformers like DK. Mario's animation is hard enough to pull off (although looking at Crystal Castles, I think a more fluid Mario should be possible), and there's also the AI of the barrels and fireballs to consider. Just looking to have a less blocky-looking Donkey Kong at the top of the screen offers a programming challenge. I don't know the first thing about programming the 2600, but I know DK is a big challenge. And I like to think someone will someday rise to that challenge. That's why I consider it a holy grail of sorts.

The CV has two main display modes: In mode #1, the CV cannot display more than two colors per 8x8 tile, and in mode #2, the limit is two colors per line in each 8x8 tile. With black being always one of the colors, that leaves only one color for the maze. This explains the monochromatic mazes in Ms. Pac-Man, and there's sadly no functional work-around possible.

Actually, I happen to own a modded CV power supply (for use with the stand-alone Adam Memory Console, obviously, not the Expansion Module #3), and it powers a little bit more than just the cartridge port. You can press the reset button and access the built-in SmartWRITER, and the keyboard fully works! The tape drives don't work, and since there's no printer, there's no point in using a word processor, but it makes me wonder if software on a CV cartridge could access the Adam's 64K of RAM. Also, with this setup, one can use the monitor-type output instead of the crummy standard RF. Also, about eColeco, I wouldn't order their "Adam Game Power Supply", because all their power supplies have rusted prongs. They work, but they're not exactly "reassuring". doubledown made a couple of modded power supplies for me (he even added an ON/OFF switch on the wire, which eColeco's PSs don't have) and they work great.

Well, there has to be a breaking point in software support somewhere between hardware generations, so since the GC is already badly supported, there's no point in kicking a dead horse. Nintendo might as well go with the Wii full steam, but I'm worried about the Wii for another reason: Will there be sufficient third-party support for the Wii? I know the Virtual Console is getting a lot of third-party attention, and the next six months look good for the Wii in general, but there were specific reasons why the Game Cube fell far behind in third-party support behind the PS2 and the Xbox, and I'm just wondering if Nintendo has changed anything in their business practices to address these issues. If not, then I have no reason to believe that history will not repeat itself, even if the PS3 doesn't live up to expectations. Third-party developers and publishers will always go with the most profitable avenues.

There's no real profit in it. All the money acquired from the sale of homebrew games (like the ones sold by the AtariAge store, for example) usually goes into paying for the carts, labels, manuals and boxes. All that is expensive, you know, so the games are basically sold at cost, so that people will actually buy them. Any profit margin you can expect is mere pocket change.

Is this new version of Donkey Kong actually available to play on MAME? I'd sure like to try it! There's johnnywc's Champ Kong for PC, which features the 4 arcade levels plus 4 new levels and a bonus level. (If the link doesn't work, try Googling Champ Kong, you'll find a mirror of the software somewhere else on the net).

Now there's a neat idea... You know, I felt really depressed for a while after seing your responses to my posts, not because my arguments against OOP were debunked (I'm big enough to take a good counter-argument), but because it made me realize how much I still have to learn. Like I've said before, I haven't had the best teachers, and all the books I've read on the subject only cover the basics ("yes, I know what inheritance and polymorphism are, can we please move on???"). I'm at a point where I need some hard experience, or at least some real code to study and learn from. My main problem is that my life is already full of things I need to do, and what little free time I have is spent on more or less trivial things (like posting on these boards, for example). I talked to my boss today about it, and he told me he's got plans for me in terms of Java development, so I can be at least a little bit more hopeful. One thing that I do not want to do is learn Java and C++ at the same time. I tried it before, and it confused the hell out of me... That's one of the main reasons why I stopped working on the BasicVision project, months ago (lack of free time and motivation are the other reasons) but darn it, I WILL get back into that project eventually, if it's the last thing I do! Yeah, that would be me, at this point in time. That's assuming the original code was well-designed... I'd follow that advice, but every programmer in my office uses NetBeans, so ditching it myself is not an option. I agree wholeheartedly. I always thought that the Java 2 bloatware was a mistake. Sun got better about including only necessary features in future revisions, but they can't go back and decrudify the Java 2 mistake. And that reminds me, there's also the whole deal with making GUI interfaces under Java. I've done a couple of them in an academic situation (using Swing), but getting into it seriously is going to give me headaches, I just know it. I better go buy some Tylenols... I'll keep that advice in mind. Thanks.

Nonsense. You have to learn to walk before you can run. In the case of programming, "walking" means being able to put one instruction after another. I've taught programming to quite a few people in my days, and you know what one of the biggest beginner mistakes is? Realizing that one instruction flows to the next! It may seem so stupidly simple to you and I, but to the programming illiterate, they fail to understand why just having the command there doesn't work. (I remember making similar mistakes when I was a child. I misordered the IF statements in a slot machine program, and thus failed to catch more massive payouts.) Computers have gone from simple to complex. As a result, one of the best teaching methods is to take a student from simple to complex. I usually prefer the following track: Line Procedural Programming -> Function Procedural Programming -> Object Oriented Programming Each step adds another layer of complexity, but only after the student is ready to absorb that complexity. I guess I can agree with that kind of logic up to a certain point. My only question is this: At what point should we leave "line procedural programming" behind and have a different starting point for introducing computer programming to kids? I can't imagine kids still using C64s 100 years from now... Now there's a good way to screw him up for life. We're supposed to be teaching children, not torturing them! Visual BASIC is not real programming. You can accomplish real programming, but only after you wrestle with all the RAD tools so you can get some real work done. I've found that the VB "language" is best approached after one has a firm grasp on computer fundamentals. Only then can one see through the haze to understand what the VB runtime is doing. Otherwise, programmers just take shot after shot in the dark, trying to tweak the VB code to do what they need. Honestly, I can't think of a single thing that has done as much damage to the computer industry as Visual BASIC has. It depends on how you look at it. From a programming standpoint, it's true that VB doesn't have much going for it, but when it first came out, VB offered the novelty of building an interface with nothing more than a mouse and then coding the application behind it. It's been done in other IDEs, and perhaps it's not the ideal way to work, but it's user-friendly enough for anyone to get into it. I guess that's where we differ you and I. To me, a massive OOP application that is badly coded is the worst nightmare imaginable. Of course, if it's well-designed, then maintaining an OO application is indeed far easier than any procedural equivalent. But in real life, well-designed OOP is somewhat of a rarity. Fixed it for you. Yeah, okay, you got a point there. I don't understand your point here. A single class cannot double the complexity unless the class is poorly designed. (Ususally, thousands upon thousands of procedural lines of code stuffed into a single class. Yuck.) There's also nothing inherently exponential about OOP design. It can be as flat, or as heirarchical as you want it to be. I've seen some pretty bad OOP designs where the entire application is shattered into billions of tiny objects, with just one or two monster objects controlling everything, but then I've also seen millions of lines of spagetti procedural code that's even worse to maintain. Both come back to poor code design, and have nothing to do with the abilities (or lack thereof) offered by OOP vs. Procedural design. Perhaps we're simply not seing the term "complexity" in quite the same way. For example, when I say that I've seen the inclusion of a single class double the complexity of an application, what I mean is that the new class was so alien to the initial design that a lot of the code in the other objects of the application had to be adjusted, modified or even augmented. And yes, it was admitedly a badly-designed application from the beginning. To me, that's added complexity. Such is life. The same is actually true with procedural programming, it's just that maintenece on procedural code tends to require a massive scaling of programmers, where most OOP environments attempt to constrain the number of programmers to keep too many cooks from spoiling the broth. The best solution in both cases is to keep up on your code refactorings. If ugly code is refactored as needed, then a redesign/rewrite can be considerably slowed. Eventually you will reach a point, though, where the entire codebase will need a rewrite. For an example, I point you to Netscape->Mozilla. Netscape Inc. just couldn't take the code any farther, so a ground-up rewrite was necessary. Netscape was not OOP code. I get that. Perhaps my experience of procedural programming is overshadowing my limited experience in OOP a little too much, but I've found that when an initial application design is faulty, having the data separate from the functions (unlike OOP which encapsulates both together) makes major design corrections a little easier to manage. But then again, I've always had a VERY modular approach to procedural programming, so perhaps my argument is not very solid to begin with. Utter nonsense. If you can't handle your code without an IDE, then you don't know what you're doing. IDEs can provide a lot of helpful information and tools, but they're nowhere near required. I like Netbeans, myself, but I still work on exceedingly complex projects with nothing more than JEdit, the JDK, and regular JavaDocings. You have my respect, sir. I have such a hard time keeping up with everything inside OO code that I give myself headaches if I stick with it for too long. An IDE gives me some tools to aleviate that problem, but the problem is still there. Java eats a base 20 megs for all the libraries it loads. Most of that gets swapped out to disk after the load. The remainder is as big as your program is. Something like JDiskReport will only show a few extra megs of usage, while something like Netbeans can balloon to well over a hundred megs. Similarly, something like Stella can show only a few megs of usage, while something like Firefox can balloon into several hundred megs. Is that supposed to impress me on some level? For instance, I can't see what's so acceptable about Java eating 20 megs just for librairies. I studied SmallTalk during my university years... I never hated a language more than that one... I see what you're saying, but Java's libraries have grown so much over the years that it's become a huge issue in terms of learning Java. Most people tell me that if you need to do something in Java, chances are it's already been done by someone else in an equivalent fashion, so I just need to look for it and use it. A practical and noble idea, but tedious when you get down to doing the actual research. Yep, it's one of the things I actually very much appreciate about Java. Long, but informative. I actually like those kinds of stuffy discussions. Also, you have to keep in mind that my experience of OOP has been fragmentary, and I haven't had the best teachers, which has lead me to develop a certain distrust of OOP in general. Would you believe I haven't even yet developed the ability to spot where an interface would be useful in my Java programs? Up until now, my Java (and C++) programs have been pretty simple compared to what others have done in my company, so I haven't encountered an actual need for an interface, but I guess I'll learn as I go. I can't agree with that. I understand the concept of learning from the past to better understand the present, and someone who's very curious about all facets of computer programming should necessarily follow that precept, but I feel it's just not necessary for kids. It's a question of generations: As an analogy, you can see how a lot of kids of today who play with PS2s and Xboxes simply aren't interested in old consoles (one look at the Atari 2600's blocky graphics will make them laugh and/or yawn). They may accept the fact that old consoles played an important part in the way they play today's games, but beyond that, they don't usually feel the need to go back in time, so to speak. I agree that a lot of the academic stuff taught in computer programming comes directly from what's been done over the last 50+ years, but I believe kids can learn the material without the historical context. Note that I'm talking about kids here, not teenagers or college/university students. I agree that older computer students necessarily need a more contextual frame of reference to become good analysts and coders.