Nintendo cease&desist on a C64 port of Super Mario Bross

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238189)
So, in case of you guys didn't hear about this already, there was a Commode 64 port of Super Mario Bros. Nintendo ordered it to be taken down.

http://www.nintendolife.com/news/2019/04/remarkable_commodore_64_port_of_super_mario_bros_attracts_nintendos_watchful_eye

Considering how different the systems are (even though they share the same CPU), I think it's really impressive the game was portable at all. But it needs very special/non-standard controller, as the C64 joystick only have one button and the NES controller has 2.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238192)
They should have changed the graphics, music, sound effects and levels to make it more original so that Nintendo doesn't notice. And then they should have made a patch that makes the whole thing act like SMB1. That is a common thing to do with post-C&D games which have been refurbished into original works so that the fangame version can still be safe from the greedy hands of copyright.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238201)
Bregalad wrote:
But it needs very special/non-standard controller, as the C64 joystick only have one button and the NES controller has 2.
In the wake of the C&D, I found a random youtube video of someone playing it. They said that the game used joystick up as jump, and remaining button as run/fire – as was apparently the convention for contemporary C64 games

I thought the colors were more saturated than I remember the C64 being, but my memory is probably wrong.

One of the videos found that the developers actually explicitly implemented a special replacement for the "minus world".
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238204)
8bitMicroGuy wrote:
They should have changed the graphics, music, sound effects and levels to make it more original

Then the internet wouldn't care about it.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238206)
For anybody who's interested in the game:

Here it's introduced by the original author:
http://www.lemon64.com/forum/viewtopic. ... 62&start=0

Have a look at the two lines of blue text below the screenshots in the first post. (Especialy the second line.) :wink:
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238218)
nesrocks wrote:
8bitMicroGuy wrote:
They should have changed the graphics, music, sound effects and levels to make it more original

Then the internet wouldn't care about it.


It would have becomes Great Giana Sisters... :lol:
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238243)
The authors did it right: port the game as-is, with original assets, to raise people's interest, knowing that it will take at least a few days before Big N gets their lawyers going. Then, with sufficient people knowing about it, take it down, thus increasing the interest for it even more, then keep it available on the Internet Archive and afloat forever by enthusiasts.
lidnariq wrote:
I thought the colors were more saturated than I remember the C64 being, but my memory is probably wrong.
I would expect any normal C64 [emulator] user to immediately crank up the saturation control of their TV/monitor, though I understand that the Commodore fanboys C64 enthusiasts take pride in keeping the VIC-II's dirty dishwater palette as it is.
DRW wrote:
Have a look at the two lines of blue text below the screenshots in the first post. (Especialy the second line.)
The uploadfiles.io link? What's so special about it?
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238247)
NewRisingSun wrote:
The uploadfiles.io link? What's so special about it?

Well, the fact that it's still available at the original thread, right now, in this moment, even though we're currently speaking about the game's takedown due to a C&D. So, whoever just got to know about the game can still get it easily. But who knows how long this will stay up? That's why I mentioned it: You don't have to rely on archive sites or private messages yet. The game is still available.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238259)
Banshaku wrote:
nesrocks wrote:
8bitMicroGuy wrote:
They should have changed the graphics, music, sound effects and levels to make it more original

Then the internet wouldn't care about it.


It would have becomes Great Giana Sisters... :lol:

More like Super Homebrew Buddies
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238269)
I actually learned a new fact about the C64 from this: Apparently the Super Mario port uses "VSP", a hardware quirk that allows you to scroll the entire screen, just like on the NES, by incrementing / decrementing the 3-bit scroll on an exactly timed cycle outside the visible screen. I can imagine that must have been quite useful to port a game that relies so heavily on scrolling...

The downside is it randomly crashes some C64s. Apparently it took a few years until C64 coders worked out that it would always corrupt every 8th byte of memory, and that a possible work-around is to avoid using every 8th byte in your code / data. Quite an awkward work-around and steep price to pay for NES-style scrolling... not sure if the port goes to this extent to avoid crashes, or ignores the existence unfortunate "VSP-unfriendly" C64s? In any case, pretty awesome trick.

Generally, it is fascinating how many unintended out-of-spec tricks the C64 can be made to do. The only thing that comes close on the NES is probably Loopy-scrolling. Other than that, most out-of-spec usage just results in intermittent glitches...

As far as the C&D goes, it always baffles me how unpredictable Nintendo's takedown actions seem. Taking down this port and "Princess Rescue" for the 2600 while both "Super Mario Crossover" and "Abobos Big Adventure" are both alive and kicking after all these years is a bit of a surprise, considering how the former two are way more niche things appealing to a tiny crowd of homebrew gamers, while the latter two are directly playable in a browser, and directly profits from ad revenue / ask for donations.

Could it be that Super Mario Crossover fly under the radar, just because the N's legal team can't get Flash to run in modern browsers?... ;)
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238273)
Abobo big Adventure won't be on Nintendo's radar since it's not own by them but technos Japan (now defunct and own by Arc System) and isn't a trademark of them either. Super Mario bros, on the other hand, they own.

As to why is Super Mario Crossover was not affected, my guess would be it's a rom hack and not a port of the actual super mario bros game so it does make a difference.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238274)
If scrolling is that problematic, how did Giana Sisters scroll?
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238282)
As far as I know it, on the C64, there are registers for a fine scroll of only 0..7, after which point games normally have to manually shift the entire screen data by 1 column.

Home computers (/ old IBM PCs) that didn't have any fine scrolling regs in hardware had to manually shift the entire screen data around to get any kind of scrolling. Which is why many games either had choppy scrolling or did it in 8/16 etc pixel increments.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238287)
ccovell wrote:
Home computers (/ old IBM PCs) that didn't have any fine scrolling regs in hardware had to manually shift the entire screen data around to get any kind of scrolling. Which is why many games either had choppy scrolling or did it in 8/16 etc pixel increments.
Actually on PC you can do vertical scrolling by tiles (if you have enough video memory), but I don't know if this feature was ever used. Horizontal scrolling is also possible although since the next tile in video memory after the rightmost tile is always the leftmost tile of the next row, the program will still have to deal with the edges of the screen after scrolling since it can't store them in video memory; I don't know if horizontal hardware scrolling was ever used either.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238291)
The PPU was custom-made and designed for games, so I guess Nintendo made sure it had things like a good sprite system, a somewhat rich colour generator with colours that are actually usable for art, and fine hardware scrolling in both axes with 4 screens worth of video address space. On the other hand it doesn't have a graphic mode for plotting lines and such that home computers had but games don't really need. RAM is also very small compared to home computers of the time. And still the Famicom exceeded its initial budget during development.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238292)
zzo38 wrote:
ccovell wrote:
Home computers (/ old IBM PCs) that didn't have any fine scrolling regs in hardware had to manually shift the entire screen data around to get any kind of scrolling. Which is why many games either had choppy scrolling or did it in 8/16 etc pixel increments.
Actually on PC you can do vertical scrolling by tiles (if you have enough video memory), but I don't know if this feature was ever used. Horizontal scrolling is also possible although since the next tile in video memory after the rightmost tile is always the leftmost tile of the next row, the program will still have to deal with the edges of the screen after scrolling since it can't store them in video memory; I don't know if horizontal hardware scrolling was ever used either.


Jazz Jackrabbit might have used it?
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238293)
Bananmos wrote:
I actually learned a new fact about the C64 from this: Apparently the Super Mario port uses "VSP", a hardware quirk that allows you to scroll the entire screen, just like on the NES, by incrementing / decrementing the 3-bit scroll on an exactly timed cycle outside the visible screen. I can imagine that must have been quite useful to port a game that relies so heavily on scrolling...

The downside is it randomly crashes some C64s. Apparently it took a few years until C64 coders worked out that it would always corrupt every 8th byte of memory, and that a possible work-around is to avoid using every 8th byte in your code / data. Quite an awkward work-around and steep price to pay for NES-style scrolling... not sure if the port goes to this extent to avoid crashes, or ignores the existence unfortunate "VSP-unfriendly" C64s? In any case, pretty awesome trick.


A little more detail:

The memory corruption occurs on some C64s because when VSP is triggered (or similar situations) the VIC-II (The C64s PPU) gets a little screwy with its memory refresh cycle. The VIC-II is responsible for DRAM refresh. If I remember correctly, VSP causes the VIC-II to poke the DRAM in such a way that it sometimes triggers a refresh operation in the memory but when this happens the VIC-II's address lines are all over the place. This has the effect of the DRAM seeing a changing address during refresh and the pits from one memory cell can get overwritten with the bits from another.

The thing is, ALL VIC-IIs are effected by this and it is pretty much the minute differences in bus timing and the silicon between models that cause the VSP bug to happen or not.

The easiest way to mitigate this on all C64s is to replace the DRAM with SRAM. My C64 had the VSP bug (but not bad enough to make Mayhem crash) and replacing the DRAM with SRAM fixed it up near perfectly.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238294)
Dwedit wrote:
Jazz Jackrabbit might have used it?
EGA and VGA (and later in these legacy video modes) all supported fine scrolling (within a character cell, which is 1 to 64 scanlines) as well as coarse scrolling (start of display). What I said last time.

The 6845 in the CGA (and MDA and Hercules) "only" supported coarse scrolling, which in the graphics modes is 8x2 pixels (in 640x200) or 4x2 (in 320x200), and in text mode is one character.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238299)
zzo38 wrote:
Actually on PC you can do vertical scrolling by tiles (if you have enough video memory), but I don't know if this feature was ever used. Horizontal scrolling is also possible although since the next tile in video memory after the rightmost tile is always the leftmost tile of the next row, the program will still have to deal with the edges of the screen after scrolling since it can't store them in video memory; I don't know if horizontal hardware scrolling was ever used either.
The IBM CGA and PCjr versions of Boulder Dash managed 60 fps scrolling using the 6845 video controller.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238300)
Pokun wrote:
On the other hand it doesn't have a graphic mode for plotting lines and such that home computers had but games don't really need.

With the exception of things like Qix and Elite.

On EGA or VGA, so long as you have enough memory for about 2.5 screens, you can indeed scroll one plane. That's 2 buffers (front and back), plus at least one metatile's worth of scrolling seam at the right and bottom. This is what Commander Keen does. But you can't scroll more than one plane without doing the same tricks you'd do for parallax on an NES, Master System, or TurboGrafx-16, such as sprites drawn behind the background. Also, wrapping around at the side of the screen isn't trivial because of the linear addressing, but it isn't any more difficult to deal with than the non-power-of-two height of the NES nametables.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238337)
Quote:
Abobo big Adventure won't be on Nintendo's radar since it's not own by them but technos Japan (now defunct and own by Arc System) and isn't a trademark of them either. Super Mario bros, on the other hand, they own.

As to why is Super Mario Crossover was not affected, my guess would be it's a rom hack and not a port of the actual super mario bros game so it does make a difference.


Nah, both of your statements are incorrect. Abobos adventure is a homage to NES games in general, and does include a lot of graphics and gameplay elements from Mario / Zelda / Balloon Fight, as well as an abundance of random Nintendo characters. And a very gory showdown with the main characters from one of Nintendo's recently revived franchises as the final boss fight...

SMC is not a rom hack, but a very faithful Flash recreation of SMB1 (though it allows backtracking), with the added element of being able to play as other videogame heroes (some owned by Nintendo, some by third-party licenses). With the standard Mario/Luigi available thrown in for completion. Not at all unlike the C64 port.

The best explanation I can think of is that Abobos Adventure in particular borders offers protection as parody/satire, but that's honestly a difficult one to argue. It could just be that some people/sites are just unfazed by C&Ds. Either that, or I guess the ways of the Nintendo's legal team are just mysterious... in any case, I'm certainly happy these gems are still accessible year after year.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238338)
[url]As far as I know it, on the C64, there are registers for a fine scroll of only 0..7, after which point games normally have to manually shift the entire screen data by 1 column.[/url]

Exactly. The 8-pixel scroll helps a lot, but on an NTSC system in particular, the shifting of the entire screen willl take around half the cycles in a frame and can easily be a bottleneck. And this code is already running on a CPU approximately half the clock speed of the original one the code was written for.

With all the RAM the C64 has, a common technique is to render the next 8-pixel increment scroll early... but if your max scroll speed if 5 pixels or more you could still end up having to do and 8-pixel increment in two consecutive frames...

Not sure how fast SMB1 maximum scroll speed is, but in any case it's easy to see how the VSP trick must have been quite fundamental for getting the C64 port running with only occasional slowdowns. Even if it messes up some C64s. I just checked, and the port does in fact just accept crashes on VSP-sensitive C64s. Feel free to give it a try on yours :)

There is actually a not-too-complex HW mod that completely removes the VSP-related crashes: http://wiki.icomp.de/wiki/VSP-Fix
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238341)
ccovell wrote:
As far as I know it, on the C64, there are registers for a fine scroll of only 0..7, after which point games normally have to manually shift the entire screen data by 1 column.

Home computers (/ old IBM PCs) that didn't have any fine scrolling regs in hardware had to manually shift the entire screen data around to get any kind of scrolling. Which is why many games either had choppy scrolling or did it in 8/16 etc pixel increments.


The C64 used 1000 bytes to store character data and 1000 bytes of color attributes; an NTSC c64 made about 15,995 cycles/frame available to the CPU. A normal optimized copy loop would be 8 cycles/byte, which doesn't quite leave enough to do full screen scrollilng unless one manages some tricks. If I were trying to create an SMB-style scrolling game based on double-size metatiles, I'd have two tile sets, one of which would place odd numbered character codes on the right, and one of which would put them on the left. Switching character codes would thus implicitly move every other character left by one time without having to rewrite anything, thus cutting in half the number of bytes needing to be rewritten.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238342)
@Bananmos

I played a few stages of Abobo after replying to this message so they kind of use in "unusual" way some of the character for feeding purpose :lol: There is a few Nintendo characters here and there so satyre would be one possibility. I need to finish it someday (never played it before) and test all the options for the mermaid since eat was the wrong (?) choice :P

For the second game, never played it too, seems was wrong again ^^;; I still think the main point is that both of them are not port of actual games to another system so this may be one reason why Nintendo did nothing about it, or not.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238343)
supercat wrote:
The C64 used 1000 bytes to store character data and 1000 bytes of color attributes;


Oh yes, I totally forgot about the color attributes. That makes the VSP trick even more crucial for this port.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238995)
nesrocks wrote:
8bitMicroGuy wrote:
They should have changed the graphics, music, sound effects and levels to make it more original

Then the internet wouldn't care about it.


This - many talented people can create a mario-esque game, but having this one actually be a faithful port of the original game (within limits) is the (imo) more significant effort that makes it stand out.

Never mind turning this into a Giana Sisters-like game in terms of graphical overhaul - it's the stages and physics that make Super Mario Bros what it is. There are so many rom hacks with new levels, and so many homebrew platformer games that are arguably similar to Mario, but only a tiny sliver of these feature clever and well-designed level layouts. "Just replace the levels" is a statement that overlooks how important level design is.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238997)
zzo38 wrote:
ccovell wrote:
Home computers (/ old IBM PCs) that didn't have any fine scrolling regs in hardware had to manually shift the entire screen data around to get any kind of scrolling. Which is why many games either had choppy scrolling or did it in 8/16 etc pixel increments.
Actually on PC you can do vertical scrolling by tiles (if you have enough video memory), but I don't know if this feature was ever used. Horizontal scrolling is also possible although since the next tile in video memory after the rightmost tile is always the leftmost tile of the next row, the program will still have to deal with the edges of the screen after scrolling since it can't store them in video memory; I don't know if horizontal hardware scrolling was ever used either.


I've used the feature myself in a file-viewing program, and there was also a console driver (FANSI.SYS I think) which used it for scrolling of console-based programs that didn't perform memory-mapped screen access. My file viewer could scroll up or down at two lines/frame with no "snow" on a 4.77MHz XT with CGA card, and if memory serves it could scroll left/right at four characters/frame.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#238999)
Bananmos wrote:
supercat wrote:
The C64 used 1000 bytes to store character data and 1000 bytes of color attributes;


Oh yes, I totally forgot about the color attributes. That makes the VSP trick even more crucial for this port.


Using the even/odd scroll technique would allow the screen to scroll 8 pixels/frame using less than half the CPU time for screen redraws without doing anything exotic. If there are 64 or fewer metatile shapes, copying each metatile left 8 pixels (both character and attribute) would take 26 cycles without any raster splits to assist (5928 total). Using shape raster splits (two interrupts per metatile for a trick known early in the 64's lifetime) could cut that to 24 per tile (5472 total), and FLD raster splits (three interrupts per metatile, using tricks I first saw fairly late in the 64's lifetime) could reduce that to 16 (3648 total). I don't know why VSP should be needed for an SMB-style game when less exotic techniques would cut the CPU overhead to manageable levels.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#239019)
mikejmoffitt wrote:
This - many talented people can create a mario-esque game, but having this one actually be a faithful port of the original game (within limits) is the (imo) more significant effort that makes it stand out.


Faithful port are difficult and sometime you have to decide where you have to make compromise to make it work in the end. That's the hardest part and always have a hard time to make compromise in those case. I won't say why I'm talking about it, need to stop talking.. :lol:
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#239041)
supercat wrote:
Bananmos wrote:
supercat wrote:
The C64 used 1000 bytes to store character data and 1000 bytes of color attributes;


Oh yes, I totally forgot about the color attributes. That makes the VSP trick even more crucial for this port.


Using the even/odd scroll technique would allow the screen to scroll 8 pixels/frame using less than half the CPU time for screen redraws without doing anything exotic. If there are 64 or fewer metatile shapes, copying each metatile left 8 pixels (both character and attribute) would take 26 cycles without any raster splits to assist (5928 total). Using shape raster splits (two interrupts per metatile for a trick known early in the 64's lifetime) could cut that to 24 per tile (5472 total), and FLD raster splits (three interrupts per metatile, using tricks I first saw fairly late in the 64's lifetime) could reduce that to 16 (3648 total). I don't know why VSP should be needed for an SMB-style game when less exotic techniques would cut the CPU overhead to manageable levels.


I think you're missing the point here. The game doesn't have half the screen time or even a quarter to spare - it's already showing significant slowdowns in places, precisely because it is running code that was written for another gaming system, where the 6502 is clocked almost twice as fast.

Yes - as other have pointed out - it's perfectly possible to do a mario-esque game on the C64, and with good coding it's probably feasible to it all with conventional 8-pixels only HW scroll, for greater compatibility. But the point of this port was obviously to make it run the original SMB1 code with all subtle gameplay elements intact, except for the necessary concessions due to the different video/sound hardware.

Making that original SMB1 code (which again, was designed for a CPU clocked almost twice as fast) run on the C64 without introducing even more lag would have required finding some major speed optimization opportunities in the original code. And even if such opportunities were identified, it's highly likely that compromises would need to be made, gameplay would change slightly, and the end product would be a subtly different game.

Personally, I think this port is a beautiful effort, despite having to resort to techniques which lower compatibility. That was one of the sacrifices that were needed to keep the lag down. And to the people who will be running this, I don't think getting either a VSP-friendly C64 model or performing the documented HW mod is out of reach.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#239044)
Bananmos wrote:
I think you're missing the point here. The game doesn't have half the screen time or even a quarter to spare - it's already showing significant slowdowns in places, precisely because it is running code that was written for another gaming system, where the 6502 is clocked almost twice as fast.


I guess I would have expected that the game would be using code written to use different time/space trade-offs targeting a system with 64K of RAM versus 2K. Unlike Warren Robinett's Adventure, where the bat, dragons, and magnets all need to be processed every gametick regardless of whether they're on screen or not, SMB ignores everything that isn't on the screen, and never really has all that much going on except maybe when the hammer-throwing dudes are on screen and if memory serves most of the rows of tiles on screen at that point are either blank or repeating.

If the game actually uses NES game logic, that would be interesting, but I'm not sure how one could sensibly make the game play precisely like the NES version unless one were to have objects either become active only after they've fully scrolled onto the screen, or cease to be active before they reach the left.
Re: Nintendo cease&desist on a C64 port of Super Mario Bross
by on (#239086)
supercat wrote:
Bananmos wrote:
If the game actually uses NES game logic, that would be interesting, but I'm not sure how one could sensibly make the game play precisely like the NES version unless one were to have objects either become active only after they've fully scrolled onto the screen, or cease to be active before they reach the left.

That's the beauty of the achievement, the port does use the NES game logic, taken and unaltered as possible from the SMB1 disassembly. Naturally the GFX, sound and I/O code had to be re-coded. In fact, the game logic is as unaltered as that while the C64 version shows more horizontal playfield, sprites still appear/disappear at the NES screen boundary, meaning enemies sometimes appear out of thin air on the right side of the screen for example.