Homebrew=Completing The Uncompleted?

[CV Gus]

Last night, I was playing Matt Patrol for the ColecoVision.

 

The 3-level scrolling on this game is amazing, and it very much captures most of the essence of Moon Patrol- although the ridiculous brassieres spoil it.

 

Then I looked over a photo of CV Joust.

 

 

Does anyone have any plans to complete these sort of games? Redoing the ships in Matt Patrol and adding in missing elements (uphill would be a problem, but is it really needed, as long as the boulders are there?)? Adding sound and title screen in Joust?

[+thegoldenband]

This topic died on the vine! But it's an interesting topic. What are the ethics involved in finishing someone else's incomplete homebrew game?

 

Also, it gives me an excuse to mention that I'd love to someday see a completed Shadow Keep for the 2600.

[potatohead]

I think if someone is serious, they should just start working on it, then when they've got a feel for the project, ask!

[Nukey Shay]

What are the ethics involved in finishing someone else's incomplete homebrew game?

 

Unless you have permission from the original author, it falls under the scope of "hacking". In hacking, there are no rules. Do what you want to do to make a more-faithful or complete game. Seeking to make a dollar off the work done...or continuing work after being warned by the author...is another ball of wax entirely. That heads down the road marked "theft"...so tread lightly.

 

Also, there are many more programs other than just homebrews that could be considered "incomplete". Even commercial successes such as 2600 Missile Command had (and still has) missing elements.

/plug

[newcoleco]

Unless you have permission from the original author, it falls under the scope of "hacking". In hacking, there are no rules. Do what you want to do to make a more-faithful or complete game. Seeking to make a dollar off the work done...or continuing work after being warned by the author...is another ball of wax entirely. That heads down the road marked "theft"...so tread lightly.

 

Also, there are many more programs other than just homebrews that could be considered "incomplete". Even commercial successes such as 2600 Missile Command had (and still has) missing elements.

you talked about continuing an homebrew game?... you should contact the author before starting, even if the game is not original.

[+intvnut]

Unless you have permission from the original author, it falls under the scope of "hacking". In hacking, there are no rules. Do what you want to do to make a more-faithful or complete game. Seeking to make a dollar off the work done...or continuing work after being warned by the author...is another ball of wax entirely. That heads down the road marked "theft"...so tread lightly.

 

Also, there are many more programs other than just homebrews that could be considered "incomplete". Even commercial successes such as 2600 Missile Command had (and still has) missing elements.

you talked about continuing an homebrew game?... you should contact the author before starting, even if the game is not original.

 

I guess it also depends on what license the original was released under. I've released a number of what can at best be called "protogames," such as "Tag Along Todd" under the GNU General Public License. Anyone can take any of these at any time and change them into whatever they want at any time, so long as if they release the result, they too release it under the GPL. In fact, David Harley took Tag Along Todd 2 and put much more of a game around it. He didn't need to ask for permission. He was able to just go do it.

 

Of course, I think I may be a tad unique in this regard in the homebrew community. *sigh*

 

FWIW, Space Patrol's teaser edition source is out there and it's GPL. I will eventually release the full level data GPL, though I'll keep the LTO splash and any easter eggs private. :-)

[TROGDOR]

I see Atari homebrews as something different than most software programs. Atari games fall more under the category of art, and I think that's why most homebrewers are protective of their code.

 

The best analogy I can think of is painting. If you're working on an elaborate painting, you might want to show your progress to friends. But it can be awkward when a friend makes a suggestion (hey, you should paint a couple trees in that corner, and you think to yourself, I really don't want to paint any trees in that corner.)

 

Then if you take a long time to finish the painting, someone comes along and starts finishing the painting for you. It may make the painting better, or worse, but it still feels like creative encroachment. Two things you seldom see collaborative work on are paintings and books, because they are very personal creative endeavors. Video games are similar, and I think the only reason most video games have multiple contributors is the fact that most video games (beyond the scope of the Atari 2600) require so much effort that only a group of people could ever hope to complete it.

 

Granted, my games will take eons to complete, but I've never abandoned them. I always come back and continue work.

[+batari]

Unless you have permission from the original author, it falls under the scope of "hacking". In hacking, there are no rules. Do what you want to do to make a more-faithful or complete game. Seeking to make a dollar off the work done...or continuing work after being warned by the author...is another ball of wax entirely. That heads down the road marked "theft"...so tread lightly.

 

Also, there are many more programs other than just homebrews that could be considered "incomplete". Even commercial successes such as 2600 Missile Command had (and still has) missing elements.

you talked about continuing an homebrew game?... you should contact the author before starting, even if the game is not original.

 

I guess it also depends on what license the original was released under. I've released a number of what can at best be called "protogames," such as "Tag Along Todd" under the GNU General Public License. Anyone can take any of these at any time and change them into whatever they want at any time, so long as if they release the result, they too release it under the GPL. In fact, David Harley took Tag Along Todd 2 and put much more of a game around it. He didn't need to ask for permission. He was able to just go do it.

 

Of course, I think I may be a tad unique in this regard in the homebrew community. *sigh*

 

FWIW, Space Patrol's teaser edition source is out there and it's GPL. I will eventually release the full level data GPL, though I'll keep the LTO splash and any easter eggs private. :-)

I don't think GPL is suitable for some 2600 asm. If homebrewers want to GPL their game logic, that's fine. The problem comes when they try to GPL kernel or kernel setup code. Kernel and kernel setup code is almost invariably derived from commercial or other non-public domain sources, and aside from it being questionable to GPL code that isn't really yours, the GPL essentially mandates that it be extended to any code that uses the same constructs. Still, some have GPL'ed their 2600 kernel code anyway. We've had this debate before - it should be easy enough to find.

 

I'm not against open source, in fact I like the idea. IMO, the biggest flaw with the GPL is it allows others to sell your work for profit. Homebrewers want to earn royalties, however meager, for their own work, or even if they don't sell it, they at least don't want others selling it. This last reason is why I used a BSD-style license with bB.

Edited May 24, 2008 by batari

[+intvnut]

FWIW, Space Patrol's teaser edition source is out there and it's GPL. I will eventually release the full level data GPL, though I'll keep the LTO splash and any easter eggs private. :-)

I don't think GPL is suitable for some 2600 asm. If homebrewers want to GPL their game logic, that's fine. The problem comes when they try to GPL kernel or kernel setup code.

Unfortunately, GPL in part of an application makes the whole app GPL. These little ROMs don't have a strong notion of dynamic linking to system libraries. The closest you'll get is calling a ROM that is built into the unit, such as the EXEC on the Intellivision.

Kernel and kernel setup code is almost invariably derived from commercial or other non-public domain sources, and aside from it being questionable to GPL code that isn't really yours, the GPL essentially mandates that it be extended to any code that uses the same constructs. Still, some have GPL'ed their 2600 kernel code anyway. We've had this debate before - it should be easy enough to find.

I've actually started to go back and re-mark all my library code as being public domain. Really, I think I want to mark as much code as possible as public domain. What value do I derive by keeping, say, controller scanning and decoding logic out of the public domain? Now the core game logic of Space Patrol itself is something different, but most of the infrastructure should be free for the taking.

 

Things are perhaps different in the Intellivision world, since pretty much all the existing homebrew games are from-scratch works, or at least not hacks of existing game carts. The simpler architecture does not require as much baseline cleverness to get started. Intellivision games often do not have a notion of a "kernel" like the Atari games do. When they do, it's really just a big "blast the GRAM and STIC" loop in the ISR--somewhat of an inversion from what you need to do on the 2600.

 

An aside, since I'm the Intellivision person at the Atari party: My understanding of 2600 programming--and you can correct me if I'm wrong--is that you implement most of your game logic in the vertical retrace interval, and spend the bulk of active display chasing the refresh, filling a line buffer up with graphics to display ahead of the actual refresh. Writing to WSYNC stalls the CPU until the next scanline, allowing you some flexibility in your timing, so that you're synchronous to horizontal retrace even if you're not pixel synchronous. Thus, games tend to adopt a kernel/logic structure, where the kernel focuses just on display, and the logic outside the kernel implements the rest of the game. This is, of course, a simplification over what's possible, such as going half-res vertically or otherwise allowing certain rows to repeat to implement other logic during active display.

 

Did I roughly capture the paradigm?

 

On Intellivision, it's somewhat reversed: Certain registers and RAM (the STIC and the GRAM) are only available during vertical retrace. The STIC, whose registers control sprite positions, contain collision information, etc. is available for about 2000 cycles after the retrace interrupt, and the GRAM is available for about 3800 cycles. Thus, games like Space Patrol also end up with a sort-of kernel/logic structure, where there's a big "blast the hardware" loop in the interrupt handler, and the rest of the logic is outside that. The difference is that the game logic happens during active display and the "kernel-like" bit happens during vertical retrace. The other big difference is that the Intellivision programming is only ever synchronous to the retrace interrupt, and never to something as fine grain as a scanline. This makes it easier to program at a corresponding loss of flexibility.

 

 

I'm not against open source, in fact I like the idea. IMO, the biggest flaw with the GPL is it allows others to sell your work for profit. Homebrewers want to earn royalties, however meager, for their own work, or even if they don't sell it, they at least don't want others selling it. This last reason is why I used a BSD-style license with bB.

You realize, of course, that the traditional BSD licenses are even more permissive about others taking your work and profiting from it, right? For many years, the TCP/IP stack and tools that Microsoft shipped (back in the Win3.1 days) was pulled directly from the BSD source tree.

 

I guess my point in saying I'm GPLing Space Patrol is more that I'm inviting others to come and build off of what I've written--including taking pieces and using them to make unrelated games. I should also add in there that if there's some piece that looks like it's more infrastructure than game, I'd be open to putting it in the public domain, since there's a dearth of quality, unencumbered code out there for Intellivision. It sounds like the situation on the 2600 side of things is simply murky with so many games being hacks of existing code or otherwise derived from proprietary sources.

 

The sales situation also seems to be rather different on the 2600 side vs. the Intellivision side. On the Intellivision side, it's much harder to make cartridges, so in practice, I'm the only person who does any more. For their releases, the IntelligentVision guys licensed the design I commissioned and use, but they're no longer making releases. Nothing stops others from making cartridges, but since it's not as simple as soldering an EPROM on a readily available blank (purchasable here in the AA store!) or desoldering a ROM from an existing board and soldering in an EPROM + inverter, no so many people are interested.

 

The thing that gets me is that on the 2600 side, it seems to be fairly easy to sell just a cartridge. When I release a game, it's a cartridge, a manual, overlays and a box. Every release has had all the elements. Perhaps that's also a big factor?

Edited May 26, 2008 by intvnut

[+batari]

FWIW, Space Patrol's teaser edition source is out there and it's GPL. I will eventually release the full level data GPL, though I'll keep the LTO splash and any easter eggs private. :-)

I don't think GPL is suitable for some 2600 asm. If homebrewers want to GPL their game logic, that's fine. The problem comes when they try to GPL kernel or kernel setup code.

Unfortunately, GPL in part of an application makes the whole app GPL. These little ROMs don't have a strong notion of dynamic linking to system libraries. The closest you'll get is calling a ROM that is built into the unit, such as the EXEC on the Intellivision.

I can see that for asm code. It all kind of fits together.

Did I roughly capture the paradigm?

Pretty well. However, most of the veteran homebrewers rarely need WSYNC in the kernel

I'm not against open source, in fact I like the idea. IMO, the biggest flaw with the GPL is it allows others to sell your work for profit. Homebrewers want to earn royalties, however meager, for their own work, or even if they don't sell it, they at least don't want others selling it. This last reason is why I used a BSD-style license with bB.

You realize, of course, that the traditional BSD licenses are even more permissive about others taking your work and profiting from it, right? For many years, the TCP/IP stack and tools that Microsoft shipped (back in the Win3.1 days) was pulled directly from the BSD source tree.

I realize that, and in a sense, my license is more permissive than GPL. Nowhere do I require that publicly released derivative forms also be open-source, for instance. I also have a so-called "advertising clause," which is the main reason BSD licenses aren't compatible with GPL. I add the additional requirement that bB or derivatives may not be sold for profit, which also does not jive with GPL.

The sales situation also seems to be rather different on the 2600 side vs. the Intellivision side. On the Intellivision side, it's much harder to make cartridges, so in practice, I'm the only person who does any more. For their releases, the IntelligentVision guys licensed the design I commissioned and use, but they're no longer making releases. Nothing stops others from making cartridges, but since it's not as simple as soldering an EPROM on a readily available blank (purchasable here in the AA store!) or desoldering a ROM from an existing board and soldering in an EPROM + inverter, no so many people are interested.

 

The thing that gets me is that on the 2600 side, it seems to be fairly easy to sell just a cartridge. When I release a game, it's a cartridge, a manual, overlays and a box. Every release has had all the elements. Perhaps that's also a big factor?

So how complicated is it to make an INTV cart? I understand the cart has a 10-bit wide data bus, so that would mean two EPROMs in parallel? Also it has multiplexed address and data buses, but is it just a matter of reading a control pin to determine address or data, and maybe writing some kind of ACK signal to show when buses are released? Also, how large are typical INTV games? Might be a project to look into some day when I'm bored

Edited May 26, 2008 by batari

[+intvnut]

So how complicated is it to make an INTV cart? I understand the cart has a 10-bit wide data bus, so that would mean two EPROMs in parallel? Also it has multiplexed address and data buses, but is it just a matter of reading a control pin to determine address or data, and maybe writing some kind of ACK signal to show when buses are released? Also, how large are typical INTV games? Might be a project to look into some day when I'm bored

The three main things are needing wider-than-8 EPROM (easily solved with a x16 EPROM such as the 27C1024), self-decoding of the address, and latching the address appropriately. There's sufficient technical detail on IntelliWiki that if you're at all motivated you can figure it out. Oh, and the data bus is a full 16 bits. It's just that the CPU is architected so that you can get by with 10-bit wide ROMs if you need to. This was a cost saving measure that made sense in 1980 but not so much today. Modern homebrews use all 16 bits since there's no sense wasting that space (since there's no x10 EPROMs but there are x16 and 2x8). Also, 16 bit ROMs confer a moderate speed advantage. Space Patrol relies on the greater density and improved performance heavily.

 

The big thing that holds most people back is the fact they can't just desolder a ROM from an old common and solder a new one in, and nobody's made their designs public. (Although, a trace of Mattel's T-Card is floating around.) This means starting "from scratch" which seems to scare folks off, though really all the information you need is available readily these days. I guess there's the small matter of making your own board, too. Doug Parsons etched his own based on the TCard design. All the carts I've produced were professionally fabbed.

 

FWIW, the largest homebrews already shipped are 16Kx16. We're working on larger games and I have a higher capacity board design in the pipeline.

 

I suggest if you're really bored, though, writing something like bAtari BASIC for Intellivision might bring a few more homebrewers to the Intellivision table.

Edited May 29, 2008 by intvnut

[godslabrat]

If a homebrew falls into limbo, I don't think there is anything wrong with stepping up to the plate and finishing it. However, I'd say it would be very poor ethics to release said homebrew in ANY form without first gaining permission from the original author.

 

On the flip side of the coin, if you've started a homebrew and decided not to finish it, you should be gracious enough to sign over the rights to someone willing to put in the work. It's all about respect for the hobby from both players and programmers.

[+Nathan Strum]

If there are homebrews out there that are unfinished and people have a genuine interest in stepping up and doing the necessary work to finish writing the game themselves, the first step is in making every effort to contact the programmer. If they can't be located and this other person is just dying to finish the game, the best course of action in my opinion would be just to start over from scratch, and code their own version of a similar game. Then they'd own it, and could change it/improve it/finish it however they wanted.

 

I don't think that would be stepping on the toes of the original programmer, since there are always going to be similar games out there. Crazy Valet and Jammed, Surround and Warring Worms, Space Invaders and Space Instigators and Rainbow Invaders and Inv+...

 

Anyway, that's just my 25¢.

Edited May 31, 2008 by Nathan Strum