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.
The title screen and the loading presentation are AMAZING. The system detection too. It almost feels like another computer. I can't say enough positives.
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...
Gameplay video:
https://www.youtube.com/watch?v=XIwlhQpC0-k
Impressive. Without the intro and careful scrutiny, I would not have realized that this is not a NES
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)
EDIT: Here's a video of the C64 version of Giana Sisters: https://www.youtube.com/watch?v=8teXm6723-g&t=1309s
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:
https://youtu.be/ZGyFQ9aRp_U?t=579
You're right, I was thinking of the SNES which had multiple background layers.
It's not near-6502 it's an exact 6502. Die-shots show the exact same transistor layout; even the decimal section is there but disabled.
There are differences in terms of some IO pins. But yes, the changes are minimal.
Oh wow, nostalgia! Giana Sisters was absolutely fantastic. I played it to death. My NES owning friends were kinda grumpy about how good it was.
I'd like to give a shoutout to machinae supremacy https://www.youtube.com/watch?v=XKkmyMKbPKE
Chris Hülsbeck https://www.youtube.com/watch?v=XKkmyMKbPKE
and all the guys at https://www.slayradio.org
for keeping the scene alive!
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.
You take that back, Mr Pibb is clearly the best. It doesn't put on airs like some other sodas.
Real Mr Pibb was awesome, although wasn't available in my region growing up.
When they moved over to Pibb Extra, that stuff was just nasty.
It's based on the reverse-engineered source code of the NES original, though.
I'd bet Mr Pibb and Dr Thunder are based on the reverse-engineered ingredients analysis of Dr Pepper.
Well, the version of Tapper I used to play on the C64 used root beer rather than so it works.
Except for the slow-downs.
Nice touch: the clock has an extra pixel on it when it’s running slow.
How did you even spot that?
In the readme:
> 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.
I find the music/audio artefacts give it away.
Even the colors look almost right - I wonder how that can be...
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.
What's up with the sound? It can't play two sounds simultaneously?
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.
[0] https://www.youtube.com/watch?v=OgFzyM3my7M
[1] https://www.retrogamer.net/retro_games80/the-making-of-the-g...
Oh, the memories. Giana Sisters was the first video game I ever seriously played.
Yup, the first thing I thought when I read the title was "well, we already had our own Mario".
To be fair, it was a decent ripoff, but controls and levels were nowhere as good as NES Super Mario.
Controlwise they were limited by the 4-way digital joystick with one fire button. They are fine what they had to work with.
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.
https://www.youtube.com/watch?v=1YWD6Y9FUuw
Well this is on the Commodore 64, and smooth scrolling was quite easy on this machine as it had hardware support for scrolling and raster interrupts.
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.
I stand corrected, as what I had mentioned was only necessary given lack of hardware support for scrolling. Good catch.
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.
That’s true, but this is from the readme
> 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.
Best explanation of vsp (or, vsp-induced crashing) I'm aware of: https://www.linusakesson.net/scene/safevsp/index.php
Interesting. So is VSP something that was officially documented, or was it an undocumented hack that was discovered?
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 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.
True, The Great Gianna Sisters scrolls just fine, and I am assuming it does not use this hack.
It probably saves a CPU cycle or two.
More like thousands.
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).
[1] https://www.youtube.com/watch?v=fdEZuK8PqLg
[2] https://www.youtube.com/watch?v=SurusNWvDmw
The EGA also had hardware scrolling though, and it was what Keen used.
But we got Commander Keen, which will always have a special place in my heart.
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).
iD made the Doom port for the Atari Jaguar, and apart from missing a few levels, was an awesome port.
It was missing the music too.
I read that book as a teenager and it made me want to start my own gaming company just so I could throw keyboards at my coworkers :D
Do you tell that story at job interviews?
Haha no but that's actually a solid idea. I've been freelancing lately but if I ever go back Ima need some material so thanks!
Which book is that?
"Masters of Doom"
> Since the NES-processor is clocked (roughly 70%) faster than a stock C64 there can be slowdowns during gameplay
Well, it's impressive that it works without being always painfully slow, then. How is this done?
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:
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.
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.
> Videos of this game in action beg to differ
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.
The original had bad slowdown too at times if I recall.
Not this bad.
This is amazing!
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.
LOL your parents were sadistic.
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.
No they aren't
https://xkcd.com/606/
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.
Cool clone, but we all know that Giana Sisters is the original game.
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.
that was my exact experience, except the germany part.
There also is a hacked version that swaps the sprites and graphics to Mario and the characters and backgrounds in that game.
Yeah, they could just have replaced the sprites in Giana Sisters to Mario and there you have it :-D
For an extremely limited port check out SMB ported to the Atari 2600 https://youtu.be/8fSO-UTdCI8
Wow, this would have been the #1 seller on the platform if it came out during the 2600's heyday. Quality is much better than most other 2600 games.
Unfortunately that port uses a 32kb ROM which likely would have never get published, due to the huge expense of doing so.
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
Meh, pitfall fit in 1/8 the rom size and actually did come out during 2600's heyday.
https://www.youtube.com/watch?v=doX3BmuoXVw
Wished they had taken the opportunity to show off the C64's solid sound chip hardware advantage over the NES ;) https://www.youtube.com/watch?v=X_cbQh8og70
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?
What is so special about this? was the C64 supposed to be not powerful enough for SMB?
The game 'Great Gianna Sisters', which exists for C64, is very similar to SMB.
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.
Actually, the Famicom (Japanese NES) came out in 1983. Super Mario Bros. was released in 1985.
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.
Also, this is awesome.
Best possible combination: Super Mario Bros for the C64 using NES bluetooth gamepads: https://youtu.be/G77mDe3NuBs
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)
> 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):
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.
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.)
https://en.m.wikipedia.org/wiki/Katakis
I think "Mayhem In Monsterland" was the most accomplished C64 platform scroller of the retro era. It has sonic-hedgehog-like smooth scrolling > https://www.youtube.com/watch?v=FsEkN_9gqOc&t=1249s
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
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.
Where we agree is R-Type. Superb.
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.
Everything in the C64 already runs at its maximum speed, or close enough to it that it makes little difference.
That is amazing work!
So nice to see that hardware continue to see development and people pushing the boundaries.
The real question now is whether 4:55 is still the fastest time the game can be finished.
It's so close to the original, that I think it's probably possible, especially if running on a turbo system.
Surely Nintendo are going to be all over this and get it removed?
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.
They don't sue, but they aggressively take down and demonetize any Nintendo related content on YouTube (even if only extremely tangential)
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.
Yes they probably will, which would be such s shame really, better download it for safekeeping while you all can! What an amazing project!
It's been pulled down from one filehoster and is "under review" on the other.
<3 Time to resurrect my C64 from the cellar. <3
I just barely learned about the (not exactly new) Star Wars RPG REUP and now I see this. Some of these fan-created projects are amazing.
What next? Manic Miner for the ZX Spectrum?
Is this a reskinned Great Gianna Sisters?
No.
Seven years of dev, true heroes!
C&D any time now…
Wow, very impressive.
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...
The title screen and the loading presentation are AMAZING. The system detection too. It almost feels like another computer. I can't say enough positives.
About. Damn. Time. This is awesome.
Thank god. Now I can finally sleep at night.
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...