bmcnett

Actual Colecovision compatibility is a technical liability if your goal is to make and sell microgames to a mass market. The cheapest hardware worth mass producing in 2017 is somewhere between PS2 and PS3 in terms of capability, and it is far, far easier to pump out Coleco-era-looking games that target this actual hardware, because there is no need to fit everything into Colecovision's extreme technical limitations: no scrolling background 32 16x16 pixel sprites with 1 color each, only 4 per scanline 16 total colors 2 colors per 8x1 background pixels 1KB RAM Z80 ASM is the only programming language There is no mass market business value in producing Colecovision games in 2017, because the cost of dealing with the above limitations vastly exceeds whatever profit could be recouped. So anyone who wants to make big money from the Coleco name these days, wouldn't be interested in Colecovision games per se. They'd be more interested in a fantasy platform like pico-8 that provided the same nostalgia feel, but which didn't have expensive technical limitations.

You know what's lewd, guys? When you're playing Smurf Rescue and you deliberately retreat from the final screen, knowing that it will cause Smurfette's dress to disappear for a few video frames.

Your theory makes more sense now that you've gone into more detail. This does assume that Coleco has a poor understanding of the retro computing scene, which is possible. Historically, a commercial platform holder's ability to control brand perception flows from their power to block distribution of games. Colecovision was the last major game platform to implement no hardware controls to lock out unauthorized games, and this is cited as one of the reasons it eventually failed. The pico8 homebrew platform holder manages to block distribution of lewd / infringing games without hardware controls, but he does this by maintaining the free BBS and free game download system that are convenient for people to use. If Coleco is a homebrew platform (it is right now) it would probably have to work more like the pico8 model, since there's no money involved.

"Strong arm the community into making you more money" this, I don't buy. the kind of money thrown around on coleco homebrew, as i understand it, amounts to probably a few grand a year, total? i have no idea really, but this seems like a reasonable first guess. so an attempt to horn in on that money would net you what, a few hundred a year tops? it just doesn't make sense to me that this is a move to squeeze money from the homebrewers - unless the scale of their operation is much, much larger than it appears to an outsider like me.

Heh, I didn't know it had sold this well.

*Should* the Coleco owner have gone after this fan page, in this way? Well no, probably not, because of the Streisand effect: those who attempt to forcefully cover things up on the Internet tend to achieve the opposite result. If a person under the age of 30 who knows how the Internet works had been consulted before action was taken, things could have gone a lot more smoothly, probably... My imagination can still imagine that somewhere, a businessperson is considering releasing a say, Raspberry Pi powered microconsole for $40, that comes preloaded with official Coleco, but which could also run NES favorites, etc. If the price were lower than NES Classic Edition and if it did multiple consoles more smoothly, I know people who would buy such a product.

People who seem irrational often simply have poor information about the decisions they are making. The chameleon affair tells me that there is a lack of tech and product design savvy in play. People have succeeded without them before, but unfortunately the videogame market is already fairly mature for that sort of thing to fly.

While technically, yes, Colecovision Flashback already is the Coleco equivalent of NES Classic Edition, it went on sale in 2014 when there hadn't yet been a runaway success in the retro console market. A business-minded person could argue that NES Classic Edition sold well partially because the platform is so beloved, and partially because a higher degree of polish went into the product itself. Personally I am not the market for any of these products, but I can't think of any other reason why the owner of Coleco would suddenly see fan-pages as a threat, where no threat had been perceived before.

Hello all, Ok so here's my view from 30,000 feet. In 2016, Nintendo's "NES Classic Edition" console was a smashing success and sold out everywhere. One of its pack-in titles is "Donkey Kong." http://www.nintendo.com/nes-classic/ This fact can't be lost on the person who currently owns the rights to Colecovision - the favored game console immediately before the original NES, which had the *exact same* "Donkey Kong" pack-in title. If I were them, I'd be thinking about attracting investors to a "Colecovision Classic Edition" product, but first I'd want to ensure that when people search for "Colecovision" on Facebook and Google, nothing sketchy appears. The crucial flaw with any such plan is that the vast majority of nostalgia-inducing Colecovision titles have always belonged to third parties, and never to the owner of the Coleco brand. Sega and Nintendo own the rights to most of those games, and would likely not participate in anything Coleco-related ever again. Anyway, this is what I think is going on here. I don't get the impression that the "homebrew community" is of any concern to the rights-holder particularly, other than it should not get in the way of business. Who am I? My dad was an Art Director at Coleco during the Colecovision and ADAM years, and I am a game industry veteran with dozens of credits on AAA titles. Bryan

AWESOME!

after reading all this i think I was wrong to say that no randomization entered the mainstream.

No, see, matthew has been talking about (eventually) offering scrolling in his enhanced 9918A but the implementation remains an unsolved problem. I happen to be working on that problem in my fake 9918A. So this is relevant to at least matthew's 9918A project. Do you have any technical opinions to offer, or are you satisfied quoting mine and replying "So what, I don't care because you're nerdy McGurdy."

I've been working on scrolling again in my VDP emulator. I'm going to have to take back my recommendation for a Game Boy-like fixed "tile window" inside of which the screen scrolls and wraps. With sadness in my heart I have concluded that Atari 400-like "display list" scrolling is ideal. That is to say, there is a data structure in VRAM that says for each scanline where to start reading tiles. I am sad because the Atari 400 way is prone to fiddly-piddly hacks - it is possible to get lost in there doing scanline breakdancing. All I want is scrolling. However a "display list" is capable of expressing all existing VDP modes OR something almost the same but with the required extra two rows and columns for scrolling without special cases for either, plus some other useful interesting scrolling methodologies, which is more than I can say about a fixed scrolling window a la Game Boy.

randomization would complicate testing because there would be far more variations than any user is likely to encounter. also the artwork and programming would be more complicated than otherwise necessary. there have been games that do things like you mention ( did black and white set game time from the net connection? ) but none so far have become mainstream because the perceived cost/benefit is too high. famous games with randomization include nethack and dwarf fortress, both quite far from mainstream gaming.

i remember my family had the 2600 w/launch titles, so that was 1977? i was five years old. most of the games required two people. my brother and i played a lot of indy 500 and combat... it didn't occur to me until years later that games could look any better than that.

There's no way Dad was responsible for Coleco's top level business decisions, he was nominally in charge of "preliminary design" or prototyping. I remember him having pride in the toys and TV shows he helped make over the years, but never games. He got his degree in industrial design in the early 60s and videogames were simply beyond his ken. Since he had no mastery of the videogame making process he simply ignored it, far as I can remember. That couldn't have helped Coleco, but in retrospect it's unclear what would.

My Dad was in charge of design at Coleco during those years. When I bumped into one of Coleco's game artists at a sushi restaurant many years later, he told me that Dad's nickname at Coleco was "Mr. Drummond." I guess this was because Dad was very "square" and looked like the television character. Dad expressed zero interest in computers or videogames until his death in 2009. I sometimes wonder if his attitude may have contributed to the collapse? Guess we'll never know.

What do most of the flickery ColecoVision games do at boot time? Call the BIOS routine that uploads the system logo and copyright screen to the 9918A. That could be the software switch that enables 32-sprite mode

This raises an interesting issue - if I'm not mistaken the 9918A and its contemporaries did all sprite work afresh with each scanline. They did not, if I understand correctly, use the VBLANK to do things like scanline-sort or otherwise process the sprite table in anticipation of scanlines to come. This made possible scanline tricks on many platforms, but also as you say would have made it expensive in hardware to do things like examine sprite patterns. I've seen MSX demos that have what look like scanline tricks, but I've never seen one on ColecoVision or ADAM, and don't know about TI-99/4A. My software VDP forbids such tricks, which enables a bunch of per-frame work to get done efficiently during VBLANK and during the frame itself. For example, batches of four scanlines are sometimes rendered in parallel ahead of the beam, which makes it possible to load fewer bits per pixel.

Yeah, that sounds exactly like my 16-bit HSV. It ended up having 32 hues and 8 saturations or 16 hues and 16 saturations, neither of which was enough to encode the 9918A's default palette IMO. I also don't have the bandwidth for full HSV, so I have both HSV and RGB palette registers, and do HSV->RGB only just after the CPU updates an HSV palette register. Multicolor mode is actually pretty cool IMO because there are so few bytes to update that an old CPU can handle it. I may keep it as a 64x48, 256 color mode which could be "faster" than the original mode, because then at least the CPU wouldn't have to deal with masking and shifting nybbles all the time.

Ah, I hadn't considered that people were using BASIC still. That case is SO cpu-bound that the four-sprite limitation is clearly superior to bit-twiddling the sprite patterns. Sorry if I'm raising a fuss - I guess I come from a different culture. I'm a ColecoVision and ADAM user, and on those platforms a no-flicker default setting is an obvious win for everyone. ColecoVision is an interesting case for homebrew because, while as a game console it was mainstream in North America, due to licensing issues and its short life there are huge gaps in its catalog that are easy to fill by amateurs (e.g. Space Invaders) and its chipset is very conventional. I thought of a flicker compromise that might or might not be useful: If on a scanline there is any sprite with all zeroes in its entire 16x16 bit pattern, then the four-sprite limitation applies to that scanline. If no such sprite is on that scanline, then the limitation is lifted.

To a PS3 programmer like me, this sounds suspiciously like an SPU but at 1/40 the speed and probably without floating-point. If I had one of these things, I could knock out emulators for old chips left and right, but I'm totally clueless about how to deal with the electrical connections to the host computer. Any pointers about what a person like me should read or experiment with, in order to reduce the cluelessness?

re: matthew's color space Yeah I'm using RGB internally like you. I do the HSV to RGB conversion only when a palette register is set, and keep an HSV copy lying around in the imaginary chip, for color key, recoloring and CPU palette readbacks. Sounds like doing this in a real FPGA is pretty hard! I admire your work ethic. I've been hearing about this "propeller" processor that can be programmed to output an analog RGB or NTSC signal from binary data comparable in density to an 8/16 bit home computer from the past. Someone got a "spectrum" emulator working, I hear. Wonder if it could do a 9918.

Since there aren't any backwards compatibility issues to consider, other than the one you just mentioned, this is where I've been doing the most radical work in my (fake) VDP. I don't understand why you would consider 9-bit colors, but I guess it has something to do with the FPGA, and I'd love to hear the story behind that one. Currently my colors are HSV (hue, saturation, value) and not RGB. Historically, HSV was used instead of RGB on older systems like 2600 because it more closely matches how an analog TV signal works. I don't care about analog TV, but I like HSV for other reasons: 1. Sprite transparency is typically done via a dedicated bit pattern (like a 0 bit in a VDP sprite.) This however consumes a proportion of colors equal to 1/(2**N) where N is the number of bits per pixel. That seems to be a reasonable tradeoff when you have four bits per pixel, because then you lose only 1/16 of your colors and you probably weren't using that color anyway. But for two bit imagery, you lose one of four colors, which is pretty horrible IMO! Therefore I would like to use "color key" for transparency in sprites. I want each sprite definition to have, in addition to X, Y, etc. a "transparent color" which is to say, a HUE which will be transparent. So a color space where HUE is a primary is convenient for that purpose. 2. The app developer sometimes desires to "recolor" imagery cheaply, which is to say for example have one sprite definition for a soccer player with a red shirt, and somehow cheaply get him to show up with a blue shirt instead. Historically this has been done with palettes, but these are usually a limited resource (e.g. Genesis had only four in the whole system) and moreover if you just want to change one color, you end up storing copies of all the other colors in each palette, which is wasteful. So I would like ANOTHER two values in the sprite definition that gives two HUES: the hue of the color you want to change, and the hue of the color you'd like to change it to. So again, a color space with HUE as a primary is convenient. 3. Sometimes the app developer wants to do something programmatically to a color on the CPU, and in my experience this is typically a change in value (brightness), hue, or saturation. If they get these as color primaries, no need for them to deal with conversions to and from a linear space like RGB, which a really old CPU is bad at anyway, because it might not even have a MUL instruction So right now, I'm considering either a 16-bit HSV color space, or a 32-bit HSV color space. Leaning towards the 32-bit because 16 isn't enough to reproduce the VDP's original hardware palette. So that would be: 16 bits: luminance, with the same nonlinearity as sRGB. 8 bits: hue. the "angle" of the color as rotated around the luminance vector. 8 bits: saturation. the "distance" of the color from the luminance vector. A 16 bit nonlinear luminance has a few things going for it: 1. You can set just the top byte and it's still sRGB so you don't lose all your dark values even though you're poking only eight bits of precision 2. If you poke all 16 bits, You won't get "banding" on any display device I've ever encountered (unlike 24 bit color!)

Whoa there cowboy, who's denigrating old hardware? The original VDP is one of my all-time favorites, and I you won't catch me saying an unkind word about it, unlike some people who can't get over the lack of hardware scrolling... The VDP mode where 8x1 pixel chunks can pick two of sixteen colors is remarkably modern if you consider how "texture compression" works on a GPU. I see a lot of hate for these modes with "attribute clash" but they are really an excellent compromise, which is why all the new graphics modes in my fictional VDP upgrade have "attribute clash!" If imitation is the most sincere form of flattery, then count me as a VDP fanboy.