Not that surprising, given the CPU in the NES is a second sourced near-6502 (Ricoh 2A03) though running a bit faster apparently. But there's nothing in there that's hard to do on a C64 (and in fact before this there was The Great Giana Sisters, released in '87, that was so similar - including a near identical first level - that Nintendo threatened to sue and it was taken out of the stores; but of course "everyone" had copies soon enough anyway)
I think the NES's PPU is a lot more powerful in some ways than the C64 VIC-II chip. The NES's PPU supports multiple background layers, priority, pixel collision detection and has up to 64 sprites on screen at once - albeit with some limitations on how many are on each scanline. The VIC-II can only do 8 sprites at a time without scanline raster tricks (and if we count those the NES can do more than 64 too)
IIRC the NES PPU only supports one background layer. You can just change the scroll position mid-frame to give it the illusion of multiple background layers.
See here for some clever examples of this technique. Everything that's overlapping is done with sprites:
This is more like off/store brand soda than anything. While not Dr Pepper, it's like Mr Pibb or Dr Thunder, still tastes good, but it's not quite the same.
> Since the NES-processor is clocked (roughly 70%) faster than a stock C64 there can be slowdowns during gameplay. A pixel indicates this on the time-watch graphics in the status bar.
There's a technique called "IFLI" that leverages the analog characteristics of 60/50fps CRTs - it's basically switching between two colors each alternating frame to "mix" two colors.
However the colors look like C64 colors. The Goombas and skin of the turtles are pink. Except possibly the Mario sprite.
The C64 has three audio channels, the NES has four. Native C64 games were designed with that in mind, but this port has to double up the NES' triangle and noise channels on one C64 voice, so sometimes a sound effect gets overwritten. The article discusses it.
I loved my C64 as a kid and played if for about billion hours. I loved the music - some of my all-time favorite "songs" are from C64 games (Ghost 'n' Goblins, Commando themes are sooo good!).
When I revisited the C64 as an adult the first thing that immediately jumped out at me was the dropped/stuck notes that happen in a theme song when you get a powerup or trigger some sound effect.
I can't believe I never even noticed it as a kid, and my brain just filled in the missing sounds!
The C64 only had three audio voices (compared to four on the NES), so it was difficult to play decent music and multiple sound effects at the same time. A lot of games let you switch between music or SFX, but not both.
Even so, its musical capabilities were years ahead of anything on the market. I usually played in music mode, if it was available. :)
There's a netradio station that exclusively streams remixes of C64 game music. It's been broadcasting for at least 20 years. It's my favorite thing to listen to while coding. https://www.slayradio.org/
This is interesting, because I used to have a bootleg “Super Mario Bros” for the C64 back in the day.
The gameplay was similar, and it certainly had characters that looked like SMB, but after about world 1-1, the game got progressively different. Like one novel element the game had were these walkways that would disappear as you walked over them.
It wasn’t a bad game. Just a different game. I think this it[0]. Apparently it’s a resedited version of the SMB knockoff The Great Giana Sisters [1], which I had never heard of until now.
The smooth scrolling is pretty hard. One of my favorite bits of Masters of Doom about id Software was when they hacked a port of Super Mario Bros 3 to the PC, but as history can tell, Nintendo didn't bite on that one.
That is true but the hardware only supports scrolling 8 pixels. After these are up if you don’t use quite exotic tricks you have to move everything that is on screen in memory manually, and the cpu is only barely fast enough to do that. It’s definitely not easy.
Yes. It was hard for Commander Keen because DOS used a screen buffer that was written to first before rendering the pixels to screen, which was quite slow back then.
In comparison, game consoles used blitting, and would directly send the lines to the CRT to draw. I assume C64 is the same.
> This port relies on the VSP-technique for scrolling. If you experience crashes while playing the game, this is most likely the issue. You may find out if your computer is prone to crashing by running VSP Lab.
I don’t know anything about the C64, but it sounds like scrolling the screen in this case wasn’t easy at all, if it required a technique that outright crashes on some C64s.
It's an undocumented hack. The C64 officially does support vertically and horizontally shifting the display one whole character position pixel by pixel by changing a register, but VSP is a hack that allows scrolling much more without copying memory.
It's odd to use for such a simple game as Mario, as I can't see how it's possibly complex enough that they couldn't afford to scroll "normally".
The CPU isn't really fast enough to fine-scroll large sections of the screen.
It runs at about 1mhz, and which means there are about 16,000 CPU cycles per frame. The CPU typically takes 3-7 cycles per instruction, so you have a maximum of 5600 instructions per frame.
The there is a useful "rotate memory left/right" instruction which takes 7 cycles. An unrolled loop of these could shift about 2000 bytes of memory left/right per frame. A 160x200 2bit color bitmap mode screen takes up 8000 bytes, so at the very least you can shift ¼ of the screen.
That might be enough for super Mario Bros, if you can be smart about empty areas.
Except, I skipped over a few things. To scroll 2bit graphics, you have to rotate twice. 14 cycles per byte, so we are down to ⅛ of the screen.
And such scrolling only works if each line uses the same 4 colors. To have more than 4 colors per line you have to shift the attribute bytes too, and deal with attribute clashes when a tile is halfway between two vic2 tiles.
You would be lucky to shift a sixteenth of the screen per frame, with zero time left over for processing gameplay and sprites.
> The CPU isn't really fast enough to fine-scroll large sections of the screen.
That's fine; it is not how you'd do it on the C64. Nor was VSP very common.
> The there is a useful "rotate memory left/right" instruction which takes 7 cycles. An unrolled loop of these could shift about 2000 bytes of memory left/right per frame. A 160x200 2bit color bitmap mode screen takes up 8000 bytes, so at the very least you can shift ¼ of the screen.
Nobody used bitmaps to for scrollers on the C64 (or indeed for most games). A game screen using character mode takes at most 2000 byes if you need to scroll the entire screen, including color RAM, which you wouldn't be doing as you'd spend some space on other things, like score displays etc., and putting more static decorations was indeed a common way of cutting down on the amount actually scrolled. Another way was to do level designs so that you did not have to scroll everything every time. E.g. by keeping some lines using the same colour, or fill part of the screen with sprites instead of characters.
To scroll the first 7 pixels in any direction then only requires updating a single register to shift the screen. This applies for bitmaps too, so there really are no circumstances where you'd bit-shift bitmaps to scroll.
For the 8th pixel you need to copy, but you don't need to complete the copy in one frame; you just need to outpace the raster-beam. So the moment it has rendered the first full line of text, you can scroll it; as long as you take care to not speed past the rendering, then you can continue following past. If you do this you have nearly two full frames to complete the copy, for about 1000 byes per frame.
C64 games mostly use the character mode in which the screen has a resolution of 40x25 characters of 8x8 ("hires") or 4x8 ("lores"; lores was most common as it allowed 2 colours plus the background colour per 4x8 character). There were exceptions, like e.g. Elite, or slow games (e.g. strategy or adventure games - the Lord of the Rings text adventure used a split screen setup using the raster interrupt to show a bitmap image on the top that was painfully slowly rendered with a tiny polygon count).
To do scrolling with the character mode you'd normally use a register to tell the graphics chip to hide 8/4 pixels on each side. You can then set the x-position and/or y-position of the viewport within that slightly reduced "window". When you've scrolled the maximum amount in one direction, the simplest approach is to wait for the vertical blank interrupt and then you copy just the 2K or less that makes up the characters on screen and whatever portion of the color attributes you need to copy. If you don't use the full height of the screen, or keep colours the same on parts of the screen, you can drastically cut the amount you copy. (Though apparently this Mario port uses VSP, which avoids the copying, but has stability problems)
Add to this that you could very precisely time things on the C64 as you can set the raster interrupt to a specific line, and the cycle count of everything on the C64 was painstakingly documented (EDIT: Though certainly not by Commodore, other than relatively high level details), and if you wanted to you could start processing the game loop while the screen was still being updated as long as you took care to ensure any rendering did not outpace the graphics rendering (if in doubt, you can check and optionally reset the raster interrupt to trigger again later on screen).
For the characters you'd use hardware sprites (most common) or you certainly could use characters "blitted" onto the screen, with the risk of making things jerky and requiring careful design as there's no way to blend against anything but the screen background colour. This was rarely done, but it happened. Barbarian II [1] at least uses that technique for at least some characters in-game, allowing bigger entities on screen (another common technique to get bigger objects is to use multiple sprites for a single in-game character). I found that out to my surprise as a child while stopping the game (which unusually for Barbarian II worked without clearing the screen) which left characters on screen representing players, not just sprites and background. Another notable one is Skyfox [2] - a 3D game where the "3D" consists of character blobs existing in multiple different sizes.
If you needed more than 8 sprites, you could use the raster interrupt to render more by resetting sprite registers after a sprite was rendered (with the caveat you could never have more than 8 on a given raster line).
It's kind of ironic, that smooth scrolling was killing PCs at the time and consoles had it easy, but then Doom came out and until Playstation no console could handle it properly (because they were so optimized for sprite based games, I suppose).
The more significant advantage of the NES over the C64 is the way hardware scrolling works.
The NES supports a 4-screen screen memory or "nametable", and the PPU, or graphics chip, can be programmed with one or two register writes to basically display any position within that 4 screens. Scrolling is just updates to the scroll registers and populating new video data on the incoming edge (which has to happen during VBLANK).
Whereas the C64's VIC-II can only select a few fixed places to start reading video memory to render the screen (2k boundaries for text mode). It can finely shift the screen left or right up to 8 pixels, but scrolling past that requires a many, many cycle recopy of RAM to video memory. Throw in the need to recopy color memory as well and that puts the C64 at a serious disadvantage.
Looks like this game on the C64 used some really advanced technique called VSP, which tells the VIC to I guess read from arbitrary memory addresses instead of the fixed ones it normally supports. This apparently exposed a VIC-II hardware bug that can corrupt RAM (since VIC-II is responsible for DRAM refresh). Really interesting. Seems some systems are more susceptible to this hardware bug than others, and there's difficult software workarounds for it.
Scrolling at most requires copying 2K. In practice much less - even without VSP, Mario levels usually have lots of long runs of the same tiles all over the screen that makes it simple to optimize the copying (or rather optimize which parts you don't need to copy).
For that matter you could double buffer and spread the copying of the tiles (not the colors) over multiple frames. The normal approach if you for whatever reason could find a way to copy what you needed, though, was simply constraining the amount of the screen you used a bit and e.g. putting extra decoration top/bottom.
But really, Mario should not be a challenge to do this for - the C64 had tons of platform games of similar complexity. Especially Giana Sisters - put this video of Giana Sisters side by side with the Mario version above from the start of level 1, and see why Nintendo threatened the publishers:
(EDIT: I've not checked, but e.g. the clouds in Giana Sisters in some of the levels looks like they might be sprites - using sprites for some of the "background" objects, especially if mostly vertically separated from the main game area was certainly a common method of reducing the amount of background that needed to be copied; notice how the levels without clouds mostly have several lines worth of tiles that doesn't require colour updates near the top and bottom, and often hardly ever requires any copying at all - e.g. mostly unbroken runs of floor tiles; many of the levels requires pretty much no colour updates anywhere)
The only reason I can see for using VSP here is because it means less need to actually figure out how to do the copying efficiently.
you don't need to double buffer to amortize the copy time. That is you don't need to do all of the copying in the vertical sync time. As long as you stay ahead of the raster you can spread the copy over the subsequent frame. So in my scrolling routine I start copying the top portion and work my way down the screen to stay ahead of the raster. Interrupts still fire during this time and handle some game updates / joystick reads.
Maybe the original game didn't always use all available cycles. But I imagine there is more to this story, I think it takes some great wizardry to make this at all. The NES and the C64 have very different graphics and sound chips.
It's a very simple game, I'm more surprised that there'd be any slowdowns. Giana Sisters copied Mario to such an extent Nintendo threatened a lawsuit, and the C64 version is perfectly fine. The C64 had plenty of other equally complex platform games.
Giana Sisters was rather simplistic compared to Super Mario Bros, with many fewer elements on screen at once, fewer animations, simpler physics, and smaller stages. Giana Sisters was great at the time but it really isn't comparable to what the developers of this clone have managed.
Size of the levels is pretty much irrelevant to the performance. Fewer elements on screen at once matters very little for performance on the C64 if they're rendered with sprites. It really does not explain the difference.
Especially not as Giana Sisters was rather simplistic compared to many other scrollers on the C64 as well.
> Fewer elements on screen at once matters very little for performance on the C64 if they're rendered with sprites
Videos of this game in action beg to differ. The only time the game seems to slow down is when there are two or more animated sprites, usually enemies, on screen at once.
This is compounded by tile-based scrolling being available in NES' hardware but not the C64, so scrolling is a costly operation — AND there are more enemies on screen at any time.
On top of this, the NES could have 64 sprites on screen at once, fully animated at full speed (barring any other slowdown). The C64 can only have 8. That's not a negligible difference. With certain tricks you can display more, but the performance of this needs to be balanced against the rest of the game: SMB already has more complicated physics and more visible items on screen at a time.
Giana Sisters was developed with the limitations of the C64 in mind. There's usually not more than one enemy on screen, the enemy typically moves slower, and animations equivalent to those on in SMB either have fewer frames or none at all.
> This is compounded by tile-based scrolling being available in NES' hardware but not the C64, so scrolling is a costly operation
It's not a particularly costly operation because you scroll character buffers, and can chase the raster beam and/or flip character buffers to amortise the scrolling (in the former case to <1000 bytes to copy for ~2 frames when you need to reset the pixel shift, so for every 8 pixel move of the playfield; less with even the slightest optimization such as e.g. keeping colours the same on parts of the screen, or filling parts of the screen with features displayed as sprites). In any case, this game doesn't even have that excuse as it uses VSP to scroll larger screen regions without copying, just by manipulating some registers.
> The C64 can only have 8.
Not true. It can only have 8 visible at any given scan-line. Lots of C64 games use a lot more by updating the sprite registers using the raster interrupt. See e.g. R-Type above, or Delta:
But even when that is too little, the "workaround" is simply to use characters and spend a few extra slots on the character set on slightly offset versions of the "tiles" to make it move smoother. E.g. the boss coming up here in Shadow of the Beast is using characters rather than sprites (and many of the stationary enemies in the games above as well):
So while 8 sprites per scan-line sometimes creates extra effort, it's was not that much of a practical limitation.
> There's usually not more than one enemy on screen
That's just not true, as I confirmed by skimming through the longplay on youtube just now. Even so, see the other examples for why that's a poor excuse.
> the enemy typically moves slower
Speed makes minimal difference to CPU cost of moving the sprites unless you entirely skips updates on some frames - every time you update the location costs as much whether you're moving it one pixel or two, and we're talking a handful of cycles per frame per sprite.
> and animations equivalent to those on in SMB either have fewer frames or none at all.
Number of frames equally makes minimal difference to performance; it's a handful of cycles per frame per sprite, as you change the memory position it reads the sprite data from, you don't overwrite the sprite contents.
When I was a kid, this is exactly what I wanted. We had a Commodore 64, but my parents wouldn't get an NES. They eventually got me one, but it was when all of my friends already had the SNES.
cheap, not sadistic. The end result is me being the most successful in my family with first a career and now multiple technology businesses.
I spent all that time learning C64 basic and some assembly. I used to type in games that I found in C64 magazines at the library. I had no way to save it, so sometimes it would take me multiple days.
A few times, the power was cut :-( and I had to start over.
Does not hold up nowadays, at least not for multiplayer games which is why a majority of people play. If you get the game after 5 years, most of the online games will be dead.
On the other hand, here I am, playing Counter-Strike:Source every weekend with a group of friends. But I'd say CS:S (and the older games in general) are not following the modern trend of multiplayer games. I doubt the latest CoD (whichever one it is) will be playable online in 5 years.
It is embarrassing but I really only learned more than a decade later that Giana Sisters was not the original.
In Germany, and I guess in many other European countries, Giana Sisters on C64 was really the Jump and Run game (that's what we called that kind of game back then) of the 8-bit era. Super Mario was not heard of. This all changed when the Game Boy came out because it had Super Mario, but this was of course a few years after the 8-bit home computer wave peaked here.
So many of my generation learned about Super Mario years after they knew Giana Sisters.
For those that have never heard about Giana Sisters. It is essentially a Super Mario clone with Mario and Luigi replaced by two girls - Giana and Maria. The levels and the game-play are not 100% identical by very similar.
It was sold only for a very short period of time because Nintendo intervened. It was still hugely popular and most copies were just pirated.
Some company later released Great Giana Sisters games for the Nintendo DS (and presumably some other platforms, maybe PC) with updated graphics. Roughly the same gameplay but very different look and feel.
Wow. This is the real deal, not a spritehack of Giana Sisters. Modulo a bit of slowdown, it's faithful to the original. Absolutely bananas. How did they get that high resolution with all the sprite colors?
NES is more powerful. 70% faster CPU, GPU is much more powerful. Commodore 64 was engineered in 1981 and released in 1982. NES is almost five years newer. C64 had a RAM advantage, but later NES carts had mapper chips.
Is there a list of SMB ports online somewhere? I was searching the other day and found some scattered info but didn't find quite what I was looking for.
As far as actual ports of the NES code go, I think there was one back in the day on the TG16/PCE, there was one a few years back for the Genesis/MD, and this. I also want to say I think someone ported it to the SNES?
I don't know if it qualifies as a port, but Hudson Soft's Super Mario Bros. Special for Japanese home computers comes to mind. (It completely lacks scrolling and takes some liberties with the level design and includes extra power-ups, though.)
Also there is of course Super Mario Bros. Deluxe for the Game Boy Color, ported by Nintendo themselves.
What are the biggest differences between a C64 and NES really? They both use a 6502 right? What prevents you from just overclocking the C64 to match the speed of the NES? Different memory layout?
8 bit micros of the era are much more dependent on their graphics hardware, what makes this demo impressive is that the c64 had a much more limited graphics chip than the NES (fewer sprites, fewer colors, and no support for tile based scrolling)
Pretty every scrolling game on the C64 uses the character mode as "tiles". It may well have been more limited than the NES - I have no idea what the NES hardware was like, but it reduced the amount of copying enough that it was rarely a major problem. The low number of hardware sprites usable per raster line was sometimes a limitation, but not very often - people got around it by using characters and/or careful level design.
While this is cool, I'm surprised people find this impressive - it's nothing special for C64 games. E.g. compare the Mario clone Giana Sisters (1987):
Both have heavy use of a mix of raster interrupts to scroll independent parts of the screen separately, and sprites, coupled with updating the bitmap of some custom characters.
Just a bit of trivia - both Great Giana Sisters (ie Super Mario Bros clone) and R-Type were coded by Manfred Trenz. He seemed to keep perfecting scrolling techniques & 'cloning' games.
He made a C64 game called Katakis that was so similar to the R-Type arcade game, Activision blocked its release & threatened him with a lawsuit [1] - unless he accepted a contract to make Amiga & C64 Versions of R-Type.
(He also made Turrican. The guy was a genius. His C64 games are one of the things that inspired me to become a programmer.)
Getting an exact port like SMB is very impressive both to the initiated and the uninitiated. Great Gianna Sisters aside, this SMB port is impressive. To the uninitiated it's impressive because they may have never expected the C64 could do such a thing. But that's fine.
To the initiated this port is impressive because of the level of polish; attention to detail and quality of the gameplay matching the original.
Anybody can carve wood but only a great artist can do it very well.
This is a game not a tech demo. The Shadow of the Beast was a demo even on the Amiga.
The level of polish may be artistically impressive to those familiar with the original game, but it's not particularly technically impressive. It's not a complex game by C64 standards, and to have slowdowns in such a simple game does not feel like it's polished.
I get that this is a port, and that they've more concerned with matching the original as closely as possible and less with optimizing for the C64, and that's of course a valid choice, and praising them for matching the original is not something I take issue with.
I'm just surprised that people find it impressive.
To me, looking at it, I wasn't impressed because I remember the games I played at the time, and it just doesn't compare all that favorably.
I don’t really know how the NES graphics work but the C64 shares the memory bus between the cpu and the ‘gpu’ (VIC) chip. Basically each cycle one half of the cycle the CPU gets to read/write one address and then the other half the GPU gets to read one thing. Sometimes the GPU needs more accesses and then it stalls the CPU. You can’t change the timing of the GPU because then it doesn’t output the picture at the right frame rate and you can’t change the timing of the CPU because then it clashes with the GPU. And also if you speed things up the memory runs out of spec and you run into glitches.
And then, if you would somehow speed up the CPU the software doesn’t run because most of it requires cycle-exact behavior matching the GPU.
Completely different graphics hardware, the C64 used the VIC-II, and the NES had a custom Picture Processing Unit (PPU) developed by Ricoh, among other things. The CPU is only a small part of a larger design, and 8-bit computers were created before any kind of standardization arrived.
I'm not sure. Given all the romhacks of SMW produced in the last couple of years and nobody getting sued (even though the authors are known/popular), I don't think they'd bother with suing for the C64 port. Just search for "romhack" on twitch.tv if you haven't seen those yet.
When it comes to SMW ROM hacks, nobody distributes ROMs. Instead, people release _patches_ which have to be applied to the base ROM (this is done through an IPS/BPS patching program). There's actually a JavaScript version available: https://media.smwcentral.net/Alcaro/bps/
Eh, it depends. They're pretty random when it comes to taking down fan works, though it's nowhere near as common an occurrence as the media would have you believe (as people have mentioned, sites like SMW Central and Mario Fan Games Galaxy have been going for years with no issues).
The general rule from what I've noticed is that a game tends to be taken down if most of these boxes are checked:
1. The game is a direct remake of a Nintendo title
2. It's of a certain professional quality that it can be confused with a Nintendo title
3. Said project has received heavy marketing/lots of press online
4. Money is involved in distributing the game
5. It's in direct competition with a Nintendo product coming out around this time
6. It's being distributed in a format that makes a takedown not legally risky for the company
The fact this is a direct clone of Super Mario Bros 1 and has received some free press probably won't help it much though.
I am sorry if this is off-topic, but is this board running phpBB2 from 15 years ago? I have used most versions of phpBB until 2015, they all came with so many security holes, I have been hacked so many times because of it, how is this board still up and running!?
Aside from the main topic (amazing stuff, undoubtedly). It was sooo good to visit normal forum, not Twitter, not Facebook, not Reddit, just a forum run by passionate people.
Sadly, European Union is working very hard to make maintenance of such forums almost impossible.
First we got GDPR and "right to be forgotten", so anyone can demand ones posts to be deleted. Then came infamous article 11 and 13, with obligatory content filtering. Now, there is TERREG regulation being accepted, which requires removal of "terrorists content" in 1 hour, otherwise there are huge fines. This will not stop spreading terrorist content, obviously, but a malicious person can post something "terroristic" in the middle of the night and report forum owner, who would have 1 hour to delete such content...
https://www.youtube.com/watch?v=XIwlhQpC0-k