Copyright on Vic20 Roms

[matsondawson]

At some point I'd like to release my Vic 20 emulator, but I'm a little worried about the issues surrounding copyright on the kernel/basic roms, also 1541 drive roms.
As I'd like to add a donation option to the emulator, I don't wan't whoever owns the copyrights to lawyer up and make my life a pain.
But I also don't want to release an emulator that is a pain in the butt like MESS wanting you to find the roms and put them in specific directorys under specific file names.
So I guess the question is, who owns the copyright, and are they particularly litigious.
(p.s. I did do a search for copyright, but didn't find anything relevant, but it was a man search, not a woman search)

[Pedro Lambrini]

Well, I don't know exactly where you stand legally as I don't know the intricacies of all the Commodore buyouts et cetera but as far as I'm aware the guys behind Vice use the proper ROM images in their emu and they still seem to be going fine...Maybe asking one of the guys could give you a better idea. At least one of the Vice team are members of this forum (tlr).

[matsondawson]

I was just thinking we could just rewrite the kernel/basic roms.
If we worked out the memory locations of all the procedures with inputs and outputs then got many people just to write one function, it could be done in no time.

[Bacon]

Since people have been distributing Commodore emulators with the ROMs included for over ten years, as commercial software/shareware (Power64, C64S) as well as freeware (CCS64) and free software (VICE). I don't think you'll get into any trouble.

In the strict legal sense someone, somewhere still owns the copyright to the ROMs but they haven't bothered anyone so far. It's not even certain that anyone actually knows who owns the copyrights.

Rewriting the ROMs would make the emulator incompatible with a lot of programs since programmers were (are?) very fond of tapping into all sorts of places places in them. To make them perfectly compatible you'd have to make the replacement ROMs binary identical to the originals, and you'd be back at square one.

[Mike]

Rewriting the ROMs would make the emulator incompatible with a lot of programs since programmers were (are?) very fond of tapping into all sorts of places places in them. To make them perfectly compatible you'd have to make the replacement ROMs binary identical to the originals, and you'd be back at square one.

"Are." Grinding the teeth.

While there are a lot of usable calls in the KERNAL jump table (character I/O, files, cursor positioning, time read/set, ...) there are also a lot of routines within BASIC, and KERNAL which need to be called directly.

Especially if you want to wedge extensions into the ROM routines, you'll make a lot of direct calls into very specific addresses - with exactly defined register and flag contents.

Even during the commercial lifespan, that made trouble. For example, the 1571 is not 100% compatible to the 1541, even in 1541 mode, because some routines in the 1571 were placed at slightly different addresses. This affected those programs, which loaded faster transfer routines into floppy RAM.

If you don't want to rely on these addresses, you could quite as well redesign the BASIC, and KERNAL, and DOS from scratch. Too much trouble just for wedging an extension into the OS.

[nbla000]

Just an opinion, why you don't cooperate with the Vice team instead of reinvent the wheel with a new emulator ?

Why you want to release a new emulator ? Which is the reason ? I'm just curious.

tlr is a Vice team member, you may contact him for further details.

[matsondawson]

1/ It's fun
2/ I prefer c++
3/ A completely different UI to vice, with emphasis on helping developers to develop.
4/ An emphasis on exact emulation, it should do exactly what the vic20 does, down to the screen corruption when you scroll the vic too far right, or unconnected ram reads, or preventing the low 3k ram block from being used as Vic ram.
5/ Learning the exact workings of the Vic20 so I can then also convert it to a Java based version in a browser, just for fun.
6/ I doubt I'd play well with an established team
7/ Helps me with a secret project.

Mostly fun, and learning.

[nbla000]

7/ Helps me with a secret project.

Nice

[RJBowman]

Has anyone ever attempted to clean room engineer Commodore compatible ROMs?

(mod: post moved from another thread, "ROM calls and other tricks", to here)

[Wilson]

Has anyone ever attempted to clean room engineer Commodore compatible ROMs?

IMO that would be a waste of time. The ROMs' functionality has been thoroughly documented line-by-line, so it would be a matter of time more than research to replicate their functionality. Even so, the result wouldn't be that useful. Too many programs bypass the KERNAL vectors to save a level of indirection or rely on other routines in the ROM code. JiffyDOS, a commercial product, is a patch on top of the official Commodore KERNAL, and no one seems to be complaining about it (nor should they).

Edit: basically what Mike said 10 years ago.

[RJBowman]

When VTEC wrote their Apple II compatible ROMs for their Laser computer back in the 80's, they disassembled hundreds of popular programs to find all of the ROM entry points in use, and managed to produce a machine compatible with about 95% of existing software (there was some disagreement about this figure).

[Wilson]

When VTEC wrote their Apple II compatible ROMs for their Laser computer back in the 80's, they disassembled hundreds of popular programs to find all of the ROM entry points in use, and managed to produce a machine compatible with about 98% of existing software. It's not impossible.

98% compatibility would probably be pretty easy. But the question is: why invest that time? The number of people stressed by the idea of using official ROMs is certainly close to 0%. I know from experience (trying to make a clean room implementation of JiffyDOS) that it's not a fun thing to work on. And you invariably begin to question whether or not you violated some rule.

[bdk6]

And you invariably begin to question whether or not you violated some rule.

And whether you did or not, if the corporate lawyers come calling claiming you did, you will run out of time, energy, and money LONG before they do. So you lose anyway.

[Mike]

[...] they disassembled hundreds of popular programs to find all of the ROM entry points in use, [...]

Given the number (surely in the order of hundred thousands) of existing programs for the C64 (and VIC-20), I'd rather err my estimate to the side, that each and every instruction opcode byte of BASIC and KERNAL potentially could serve as valid entry point. Likewise, all table data could be somehow be referenced by some 3rd party program. There is no abstraction layer whatsoever (the KERNAL jump table being a honorable exception) which would help here.

In other words: if you begin to change the ROMs, you just enter a continuum where more and more programs fail, in proportion to the amount of changed code. A clean room implementation of the ROMs will probably approach 0% compatibility, save for pure BASIC programs and those few machine code programs which just reference the KERNAL jump table.

[Wilson]

...save for pure BASIC programs...

Mhmm, and it's only the large number of those that makes high percentage compatibility achievable. But, as you say, that is a low bar. That percentage would diminish almost proportionally to the quality of the software.
The 901486-06/07, every byte of it, is part of what defines the Vic-20.