Reusing Kernels

[~llama]

Are we going to be allowed by Infotari to reuse a kernel from an Atari VCS game? not really the whole kernel, just... portions of the kernel code?

 

What are the copyright implications of re-using an Atari kernel?

 

Just wondering, for future development purposes

[kisrael]

Are we going to be allowed by Infotari to reuse a kernel from an Atari VCS game? not really the whole kernel, just... portions of the kernel code?

 

What are the copyright implications of re-using an Atari kernel?

 

Just wondering, for future development purposes

I'm not a lawyer, but I would guess that you'd be protected in two ways:

* security through obscurity...chances are Infotari isn't deeply examining "infringing" works, they just want to "protect" their trademarks and copyrights from obvious infringement. So if you took portions of a kernal code, and the graphics and/or gameplay weren't direct ripoffs of something, you probably wouldn't have an eyebrow raised at you.

 

* There's some evidence that suggests code-sharing was rampant, most particulary within companies but sometimes people would take their knowledge with them to share. So I guess there's precedent.

 

So, really, I think Infotari is just out to protect the "big ideas"

[NovaXpress]

I wonder how the concept of "satire" could be applied here.

[Nukey Shay]

This discussion has come up before. The simple answer was not to IF you are looking to create a marketable product (since there's no telling how much money a corporation would sink into fighting an individual). Due to fair use laws, the copyright holder would be almost 100% certian to lose the case IF there are no trademarks or patents involved and IF the hacker has the time and resources to combat them. Since most people have day jobs and don't have time for litigation, the copyright holder would win by default IF they decide to aggressively pursue the case (however unlikely concerning dead products...due to the fact that it would just cost them $$$ and create bad PR).

 

So hack away. If you don't really have the intention of marketing the hack, it will pretty much remain under their radar. And even if you do, the chances are pretty slim that the corporation would actually wage war with you (though you might get a threatening letter).

 

Now if current trademarks or patents were involved, it would be a different story. 2600 game kernals? Don't bury your head in the sand over them. Though it might be difficult to find somebody to market it for you (since their neck would be on the line). But some will.

[Cybergoth]

Hi there!

 

Are we going to be allowed by Infotari to reuse a kernel from an Atari VCS game? not really the whole kernel, just... portions of the kernel code?

 

It's impossible to not reuse portions of kernel code from one of the existing games. There's only so many ways to display a sprite, missile or ball, that everyone does it "like that". Take that famous 6-char display, there's only one way to do it right, so in it's core the techinques for every game using it are 90% identical with only very few minor variations.

 

Greetings,

Manuel

[Nukey Shay]

There's actually a few ways to do it "right" You can involve the stack, use LDY/DEC for the scanline counter or STY/LDY/DEY, you can have it execute from ram if you want to save additional cycles for color manipulations, etc. A portion is one thing, but I thought he was referring to entire displays (where the rest of the program apart from the kernal is different - but the "engine" is virtually identical)?

[Cybergoth]

Hi there!

 

There's actually a few ways to do it "right"

 

Hm... show me one that works without VDELP

 

A portion is one thing, but I thought he was referring to entire displays (where the rest of the program apart from the kernal is different - but the "engine" is virtually identical)?

 

I think no matter how similar the games get, you'll always need to customize a few things for your specific needs here and there. I don't think that Robert let the Wolfenstein kernel untouched for example. If he'd done it all secretly and claimed it being all original work, no one could prove him wrong I guess. (BTW: What does clonespy say? )

 

I'd assume at some "grey spot" eveything turns from hack to original work, but I wouldn't know how to establish a rule for this.

 

Greetings,

Manuel

[Nukey Shay]

Hm... show me one that works without VDELP

I'll go one better...show me one that works without GRP0

 

 

If he'd done it all secretly and claimed it being all original work, no one could prove him wrong I guess.

Clonespy can be easily fooled (especially if you shift ram allocation around). But a person is not so easily fooled. I just now made a raw disassembly of each, and I can quickly identify that the hack is derivative of the original...even tho the timing and instructions used are not 100% exact, and Clonespy cannot identify it.

 

Venture:

LF0EC: INC    $F5    ;5

      LDA    ($F2),Y;5

      CPY    $9A    ;3

      STA    GRP1   ;3

LF0F4: BNE    LF0E0  ;2

      LDA    #$02   ;2

      STA    ENABL  ;3

      NOP           ;2

      NOP           ;2

LF0FC: LDA    LFD16,X;4

      STA    PF1    ;3

      LDA    LFC16,X;4

      STA    PF2    ;3

      TYA           ;2

      CMP    LFF57,X;4

      BNE    LF122  ;2

      BVS    LF0E6  ;2

      LDA    LFCA7,X;4

      STA    $010F  ;4

      LDA    LFDA7,X;4

      STA    PF1    ;3

LF119: INY           ;2

 

Wolfenstein:

LF55D: INC    $F5    ;5

      LDA    ($F2),Y;5

LF561: STA    GRP1   ;3

LF563: CPY    $9A    ;3

      PHP           ;3

      PLA           ;4

      STA    ENABL  ;3

      LDA    LF20A,X;4

      STA    PF1    ;3

      LDA    LF307,X;4

      STA    PF2    ;3

      NOP           ;2

      TYA           ;2

      CMP    LFF76,X;4

      BNE    LF591  ;2

      BVC    LF57E  ;2

      BVS    LF588  ;2

LF57E: LDA    LF38B,X;4

      STA    PF2    ;3

      LDA    LF28E,X;4

      STA    PF1    ;3

LF588: INY           ;2

 

In that sense, you could take a kernal, optimize the hell out of it until it's barely recognisable from the original, but you would still end up with a derivative work (which can still be identified as such...depending on how deep the person studies them). To a hacker like me, it sucks (I can rewrite an entire program, but if it's still creating it's pretty picture based on the way a seperate program created it's pretty picture, it's still just a hack). Throw in a few graphic writes and color shifts here and there, trim out some wasteful instructions, rewrite small sections of it, doesn't matter...still a hack. Believe me, I don't agree with it any more than you do But them's the facts.

 

I'd assume at some "grey spot" eveything turns from hack to original work, but I wouldn't know how to establish a rule for this.

The rule is already there...it's called "fair use". And best of my knowledge, nobody's been busted for copying the 2600's pretty picture (threats, yes...busted, no). 'Course, that grey zone is constantly being rewritten - depending on how much the lawyers are getting.

[Thomas Jentzsch]

(BTW: What does clonespy say? )

CloneSpy says:

                                      0  1  2

0 Venture II (2001) (Tim Snider)···   · 92 26

1 Venture (1982) (Coleco) [!]······   =  · 26

2 Wolfenstein 2600·················   =  =  ·

[Thomas Jentzsch]

Clonespy can be easily fooled (especially if you shift ram allocation around)

Yup, therefore its more reliable for stuff that was made without knowing about it.

 

But a person is not so easily fooled.  I just now made a raw disassembly of each, and I can quickly identify that the hack is derivative of the original...even tho the timing and instructions used are not 100% exact, and Clonespy cannot identify it.

That's what CloneSpy says about those two short snippets:

               0  1

0 cs_wolf···   · 13

1 cs_vent···   =  ·

Not very good, but at least it still found some similarities.

[Cybergoth]

Hi there!

 

In that sense, you could take a kernal, optimize the hell out of it until it's barely recognisable from the original, but you would still end up with a derivative work (which can still be identified as such...depending on how deep the person studies them).

 

Yes, that's sort of true. But let's get back to that 6-char kernel again

 

Imagine someone with no clue about reverse-engineering or [stella] or Atari Age or anything just manages to re-invent the wheel here.

 

Now, how could he ever proove that? No matter how inventive he get's there, a 6-char kernel will look like a derivate of 6-char kernel, no?

 

Greetings,

Manuel

[Nukey Shay]

Sure...but the odds that an entire kernal written from scratch would appear to be derivative from an existing work would be astronomical. And there are some things that not everyone can spot (like a particular coding style, for example)...while others would recognise them instantly. The six-digit display might only have a small list of ways...but an entire game engine would give enough clues to the original it is based on...even if long stretches of them had been altered. And all it would take is one person to notice before the gig is up.

[~llama]

Well... basically what I had in mind was hacking the Berzerk kernel into a totally original game concept that wouldn't, in the end, resemble Berzerk in very many ways, if at all. I just wanted to reuse the portions like the "monster" AI and perhaps some of the Crazy Otto stuff... but still have Berzerk under the hood, so to speak...

 

I guess it'd technically be a hack but it'd be a hack that you'd have to disassemble to tell it's a hack at all. And I wouldn't be able to market that game? I'm fine with that, I just want to make it, but... it'd be nice to have it in cart form...

[Nukey Shay]

In that case, you'll probably get hit with the suggestions of why you don't take the next step and do a new kernal too. IMO there's no need to reinvent a wheel that already works...same goes for an engine. Many others disagree...but a fun game is all that matters I look forward to trying out whatever you come up with. By adding 30hz flicker, you should be able to remove the limitation of them not being able to cross one another's scanlines.

[MacbthPSW]

Take that famous 6-char display, there's only one way to do it right, so in it's core the techinques for every game using it are 90% identical with only very few minor variations.

Why do I always feel picked on whenever the 6-char display subject comes up?

 

I wonder if Joe still used my "wrong" routine in the new Ultra SCSIcide?

[~llama]

IMO there's no need to reinvent a wheel that already works...same goes for an engine.

 

My thoughts exactly. It'll save a lot of work and headache if I'm able to adapt the existing kernel to do what I need it to... I've never designed a kernel so maybe hacking one to pieces will teach me a lot more about them than the 2600 tutorials did (no offense meant by that, those tutorials were great)

 

But I'm thinking that I can get this to work by using the Berzerk kernel... if not I'll be designing my own anyway.

[Nukey Shay]

I've never designed a kernel so maybe hacking one to pieces will teach me a lot more about them than the 2600 tutorials did (no offense meant by that' date=' those tutorials were great)[/quote']

Not really...I've been hacking them for a while now and I still haven't learned much about designing one from scratch. And since I already know assembly in general, there's no reason to learn @ square one if a kernal exists that matches what I need. I'll leave that to the people that have loads of free time on their hands

 

For starters tho...just make sure that any changes you do will leave cycle time unaffected. Some areas depend on exact timing...while others will use WSYNC's to eat up the remaining time. It's even better if you can get your changes done before the display needs to begin.

[~llama]

Well... I'm gonna have to sit down and really figure out the Berzerk kernel before I even decide if I'm going to be able to use it. It's looking more and more like I just need to start a new kernel...

 

to see my idea search this forum for my "Phred" idea. That's what I'm still working on. I did make a quick graphic hack where you play as a crazy robot in Berzerk instead of a human but... for some reason when i changed the graphics Player 0 stopped firing horizontally and now you have to walk right up to the robot and "punch" them... check it out in the attachment. Mildly amusing.

krezreb.zip

[Robert M]

Well... I'm gonna have to sit down and really figure out the Berzerk kernel before I even decide if I'm going to be able to use it. It's looking more and more like I just need to start a new kernel...  

 

to see my idea search this forum for my "Phred" idea. That's what I'm still working on. I did make a quick graphic hack where you play as a crazy robot in Berzerk instead of a human but... for some reason when i changed the graphics Player 0 stopped firing horizontally and now you have to walk right up to the robot and "punch" them... check it out in the attachment. Mildly amusing.

 

The punching problem is because the code seems to check for the player's shot hitting the player himself and treating it like the shot hitting a wall. Very strange. You either need to change the collision detection algorithm to not include the player sprite in the player shot collision tests, or you need to set the player's shot to begin farther to the left or right to account for the wider robot player graphic.

 

Cheers!

[Nukey Shay]

I guess it'd technically be a hack but it'd be a hack that you'd have to disassemble to tell it's a hack at all. And I wouldn't be able to market that game? I'm fine with that, I just want to make it, but... it'd be nice to have it in cart form...

Sure you could. There are still people that do this (Packrat games, for example)...even though AA has dropped out of dealing with hacks (though they will still one-off anything as long as it's not currently being sold. And nothing is to stop anyone from buying a burner and doing it themselves.

[Thomas Jentzsch]

It'll save a lot of work and headache if I'm able to adapt the existing kernel to do what I need it to...

But designing the kernel is the most fun part of programming for the 2600. By far!

 

Actually I often get bored after designing a kernel and then abandon the project. So maybe we should join forces?

[~llama]

Actually I often get bored after designing a kernel and then abandon the project. So maybe we should join forces?

 

Heh... maybe so, if you really liked my idea that much... otherwise I guess I'll just... design my first kernel and learn the ins and outs of .skipDraw...

 

Well... Thomas, or really anyone who writes a lot of homebrew games, how do you usually go about designing your kernels? Do you lay them out on paper first, or just spit out a working kernel the first time you open your text editor?

I find that "metaprogramming" things before I actually write any code helps me, but... how do the pros design their kernels?

[~llama]

You either need to change the collision detection algorithm to not include the player sprite in the player shot collision tests, or you need to set the player's shot to begin farther to the left or right to account for the wider robot player graphic.  

 

Cheers!

 

Or perhaps I can find a way to make it so the robot always has to "punch" although this makes the game way to hard to be ay fun.

 

So I need to find the section of code that handles collisions between Player 0 and the missile?

[Nukey Shay]

No, it would be better to find the area of the code (away from the kernal) that sets the missile's initial location...and fudge the values there. A couple of people have worked with this game before - perhaps they'll point you to the area

[Thomas Jentzsch]

Heh... maybe so, if you really liked my idea that much... otherwise I guess I'll just... design my first kernel and learn the ins and outs of .skipDraw...

May be you could do one or two coarse but complete mockups about how the complete screen should look like? Then I would get a better idea.

 

Well... Thomas, or really anyone who writes a lot of homebrew games, how do you usually go about designing your kernels? Do you lay them out on paper first, or just spit out a working kernel the first time you open your text editor?

It's a mixture. I start experimenting with some code in the editor, go back to paper, do some more experiments etc. pp. Then I get an idea about what is possible and what not. Base on that I try to find the best compromise (cumulating cycles etc.) and test the results.

 

And even for the final optimizing phase I often go back to paper and shift around some parts of the kernel. Still about 80-90% of the work is done in the editor.