Super Mario Bros. has been released for the Commodore 64
lemon64.com
lemon64.com
EDIT: Here's a video of the C64 version of Giana Sisters: https://www.youtube.com/watch?v=8teXm6723-g&t=1309s
See here for some clever examples of this technique. Everything that's overlapping is done with sprites:
Chris Hülsbeck https://www.youtube.com/watch?v=XKkmyMKbPKE
and all the guys at https://www.slayradio.org
for keeping the scene alive!
When they moved over to Pibb Extra, that stuff was just nasty.
> 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.
However the colors look like C64 colors. The Goombas and skin of the turtles are pink. Except possibly the Mario sprite.
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!
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/
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.
[0] https://www.youtube.com/watch?v=OgFzyM3my7M
[1] https://www.retrogamer.net/retro_games80/the-making-of-the-g...
To be fair, it was a decent ripoff, but controls and levels were nowhere as good as NES Super Mario.
In comparison, game consoles used blitting, and would directly send the lines to the CRT to draw. I assume C64 is the same.
> VSP (VARIABLE SCREEN POSITIONING)
> 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.
The blast processing trick on the Genesis would be something similar then. There's a syncing issue with that one too: https://www.youtube.com/watch?v=rvvL6S5Buiw
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".
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.
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.
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).
Well, it's impressive that it works without being always painfully slow, then. How is this done?
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.
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:
https://www.youtube.com/watch?v=8teXm6723-g
(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.
Especially not as Giana Sisters was rather simplistic compared to many other scrollers on the C64 as well.
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.
That says much about this game than about C64 games in general.
Compare to e.g. R-Type (that also has much more complicated scrolling) that has no such problems:
https://www.youtube.com/watch?v=Bft5BhWIzTU
> 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:
https://www.youtube.com/watch?v=AeLi01dpME0
Or Katakis: https://www.youtube.com/watch?v=zAtW-3sx_1s
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):
https://www.youtube.com/watch?v=R_GdJiEjSho&t=78s
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.
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.
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.
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.
That’s why the quality is so much higher. It’s a great example of what can be achieved when these limitations no longer apply.
My favourite modern day Atari 2600 port is Pac-Man 4k. https://youtu.be/dAYuBcuvIww
The game 'Great Gianna Sisters', which exists for C64, is very similar to SMB.
Also there is of course Super Mario Bros. Deluxe for the Game Boy Color, ported by Nintendo themselves.
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):
https://www.youtube.com/watch?v=8teXm6723-g
To a more technically impressive C64 scrolling game like R-Type:
https://www.youtube.com/watch?v=Bft5BhWIzTU
Or Shadow of the Beast (though a shadow - sorry - of the Amiga version) with its many parallax layers:
https://www.youtube.com/watch?v=R_GdJiEjSho
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.
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.)
Some amazing C64 games are being produced in recent years, for example see this one > "Sams Amazing Journey" https://www.youtube.com/watch?v=1uHys7Vr-FY
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.
Where we agree is R-Type. Superb.
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.
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.
So nice to see that hardware continue to see development and people pushing the boundaries.
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 have been meaning to check out this book on C64 game programming, for anyone interested: https://www.amazon.com/Retro-Game-Dev-Derek-Morris/dp/069298...
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...