Maybe this will make things make more sense, this is normally the C64 high resolution mode:
If you break the image up into 8x8 tiles, you'll notice no square ever uses more than 2 colors:
By contrast, the NES can display 3 colors + transparency in every 8x8 tile. In order to display multiple colors like this on the C64, you have to use a fat pixel mode, which sacrifices half the resolution. Additionally, this high resolution mode has no real ability to scroll left or right.
Krejlooc, check these:
- Beep Boy 64: https://www.youtube.com/watch?v=QXLLFOBonfk
- Block Man 64: https://www.youtube.com/watch?v=kMNxlYMcmbs
- Cave Wizard: https://www.youtube.com/watch?v=ZauZ8stUpWk
All of these look better than the SMB port in terms of visuals, but somehow to me, these games still look worse than the best of C64 "fat pixel" mode like Mayhem in Monsterlad or Creatures.
.
Wow never heard of Mayhem in Monsterland (from 1993).All of these look better than the SMB port in terms of visuals, but somehow to me, these games still look worse than the best of C64 "fat pixel" mode like Mayhem in Monsterlad or Creatures.
.
There are advantages to the PAL C64 (some games require it) but having always had an NTSC C64, I would hate to have to use PAL speed for so many games.
Except for top row of text(which does look hi-res) - every visible pixel on rest of the screen is 'fat'. I thought at first Mario might be hi-res (hi-res main sprite wasn't that uncommon) but even that doesn't seem to be the case.Though the video feed itself has some sort of upscaling/distortion on it (no idea how this was captured), so without seeing it in a pixel-perfect capture it's hard to be 100%.There are 1 pixel horizontal gaps everywhere. Look at the pixel separating the legs of the M in Super Mario Bros, for example.
Looking at it in the emulator now - clouds are high res too, but the rest of the graphics are 'fat'.Except for top row of text(which does look hi-res) - every visible pixel on rest of the screen is 'fat'. I thought at first Mario might be hi-res (hi-res main sprite wasn't that uncommon) but even that doesn't seem to be the case.Though the video feed itself has some sort of upscaling/distortion on it (no idea how this was captured), so without seeing it in a pixel-perfect capture it's hard to be 100%.
Yeah, I think so too - both games actually have multicolor 'fat' pixel for graphics, but Mayhem has high res main character sprite for example.Wow never heard of Mayhem in Monsterland (from 1993).
SMB port looks like it's doing a fantastic job at recreating SMB, but this game is lovely looking and looks like it's doing everything visually that the SMB port is doing and more.
What about this ? I'm not sure what it's using but it's pretty damn impressive
Yeah, I think so too - both games actually have multicolor 'fat' pixel for graphics, but Mayhem has high res main character sprite for example.
By comparison, here's Hudson's port of Super Mario Bros to the PC-88 which used a superior Z80 CPU, which had similar color restrictions as the C64:
You can see the complete lack of scrolling present. The C64 uses a slightly modified version of the CPU in the NES, not something stronger, but has much more restrictive video drawing capabilities than the NES. For it to match the NES output is absolutely astonishing.
I don't think anything Mayhem does is 'normal' or usual :) It was a highly impressive release late in C64 shelf life from one of the most talented teams on the platform.Mayhem seems to freely mix 'fat' tiles and high res tiles, is that a normal C64 thing? Some levels use 2 colour animated tiles for a parallax background effect, and they're HD. other levels have 2 colour clouds and other background shading in HD.
edit: I really like how they have opted for square 2x2 pixels for all the enemies instead of the weird fat pixel look. The SMB port is doing this in a few places but not always, maybe Krejilooc got confused by those square 2x2 pixels?
That's a bitmap though. In character mode individual characters can be set to either multi-color (wide pixels) or high-res on a per character basis.Maybe this will make things make more sense, this is normally the C64 high resolution mode:
If you break the image up into 8x8 tiles, you'll notice no square ever uses more than 2 colors:
By contrast, the NES can display 3 colors + transparency in every 8x8 tile. In order to display multiple colors like this on the C64, you have to use a fat pixel mode, which sacrifices half the resolution. Additionally, this high resolution mode has no real ability to scroll left or right.
What about this ? I'm not sure what it's using but it's pretty damn impressive
One of the tricks you can do on the C64 involves manipulating the video chip into reading the graphics data at an offset from where it's usually located. This allows you to scroll the display horizontally, and the trick is called VSP for Variable Screen Position. However, some machines crash when you attempt this, and the reason for that has always been a mystery. Not anymore.
--------------
The dreaded VSP crash is caused by a metastability condition in the DRAM. Some have speculated that it has to do with refresh cycles, but hopefully the detailed explanation in this scroller will crush that myth once and for all.
But first, this is what the machine behaves like from a programmer's point of view. Let us call memory locations ending in 7 or f fragile. Sometimes when VSP is performed, several fragile memory cells are randomly corrupted according to the following rule: Each bit in a fragile memory cell might be changed into the corresponding bit of another fragile cell within the same page.
This specific behaviour can be exploited in several ways: One approach is to ensure that every fragile byte in a page is identical. If the page contains code, for instance, corruption is avoided if all the fragile bytes are $ea (nop). Similarly, in font definitions, the bottom line of each character could be blank.
Another technique is to simply avoid all fragile memory locations. The undocumented opcode $80 (nop immediate) can be used to skip them. Data structures can be designed to have gaps in the critical places.
This latter technique is used in this demo, including the music player of course. Data that cannot have gaps, i.e. graphics, is continuously restored from safe copies elsewhere in memory. You can use shift lock to disable this repair, and eventually you should see garbage accumulating on the screen. And yet the code will keep running.
Thus, for the first time, the VSP crash has been tamed.
Now for the explanation. The C64 accesses memory twice in every clock cycle. Each memory access begins with the LSB of the address (also known as the row address) being placed on an internal bus connected to the DRAM chips. As soon as the row address is stable, the row address strobe (RAS) signal is given. Each DRAM chip now latches the row address into a register, and this register controls a multiplexer which connects the selected memory row to a set of wires called sense lines. Each sense line connects to a single bit of memory.
The sense lines have been precharged to a voltage in between logical zero and logical one. The charge stored in the memory cell affects the sense line towards a slightly lower or higher voltage depending on the bit value. A feedback amplifier senses the voltage difference and exaggerates it, so that the sense line reaches the proper voltage representing either zero or one. Because the memory cell is connected (through the multiplexer) to the sense line, the amplified charge will also flow back and refresh the memory cell. Hence, a memory row is refreshed whenever it is opened.
VSP is achieved by triggering a badline condition during idle mode in the visible part of a rasterline. When this happens, the VIC chip gets confused about what memory address to access during the half-cycle following the write to $d011. It sets the internal bus lines to 11111111 in preparation for an idle fetch, but suddenly changes its mind and tries to read from an address with an LSB of 00000111.
Now, since electrical lines can't change voltage instantaneously, there is a brief moment of time when each of the changing bits (bit 3 through 7) is neither a valid one nor a valid zero. But because the VIC chip changes the address at an abnormal time, there is now a risk that the RAS signal, which is generated independently by another part of the VIC chip, is sent while one or more bus lines is within the undefined voltage range.
When an undefined voltage is latched into a register, the register enters a metastable state, which means that its output will flicker rapidly between zero and one several times before settling. This has catastrophic consequences for a DRAM: The row multiplexer will connect several different memory rows, one at a time, to the same sense lines. But as soon as some charge has moved from a memory cell to the sense line, the amplifier will pull it all the way to a one or a zero. If, at this point, another memory row is connected, then the charge will travel from the sense line into this other memory cell. In short, one memory cell gets refreshed with the bit value of a different memory cell.
Note that because the bus lines change from $ff to $07, only memory rows with an address ending in three ones are at risk of being opened simultaneously. This explains why corruption can only occur in memory locations ending in 7 or f.
Finally, this phenomenon hinges on the exact timing of the RAS signal at the nanosecond level, and on many machines the critical situation simply doesn't occur. The timing (and thus the probability of a crash) depends on factors such as temperature, VIC revision, parasitic capacitance and resistance of the traces on the motherboard, power supply ripple and interference with other parts of the machine such as the phase of the colour carrier with respect to the dotclock. The latter is assigned randomly at power-on, by the way, which could be the reason why a power-cycle sometimes helps.
Mayhem was available on the Wii VC. Unfortunately that's no longer available.
A lot of C64 games have smooth scrolling like this btw. It's not anything new - but yes the technique is somewhat insane. I don't think this is the only technique for the smooth scroll on C64, but this particular one has been invented back in the machine's heyday, and used on some games (and would cause some of the machines to crash!)The first thing I thought watching the video was "how is it possible for a C64 to scroll like that?", and I admit I was expecting you to explain the magic like you usually do, hahah.
Edit: From Popstar's link above:
Holy freaking shitballs: it's exploiting the physical / voltage level (and leaving specific memory addresses untouched to avoid crashing due to that). I'm assuming in the case of emulators, this particular quirk must be known beforehand and explicitly coded in to work like in real hardware.
I wonder if how impressed you are with this video depends on the games you played, I had a lot of scrolling games back in the day.A lot of C64 games have smooth scrolling like this btw. It's not anything new - but yes the technique is somewhat insane. I don't think this is the only technique for the smooth scroll on C64, but this particular one has been invented back in the machine's heyday, and used on some games (and would cause some of the machines to crash!)
Fun fact: So does the NES and sprites on that are 8x8 pixels, the C64's sprites are 24x21 pixels (because that's 63 bytes at one bit per pixel). The NES has to do heavy multiplexing which means swapping out the sprites after each line has been drawn (since moving the sprite after it's been drawn doesn't change the drawn pixels), hence the flickering it's known for: When more than 8 sprites are in a line then it cannot render them all. I dunno how common multiplexing was on the C64 when it was still a common platform (people come up with new tricks for exiting machines long after they stop being commercially relevant) but the larger sprites mean most characters are only one or two sprites total whereas even a 16x16 NES character is 4 sprites already.
Another cool recent C64 development has been the port of LIMBO to C64. There's a short playable demo, about a year old, and it's nothing short of astonishing,:
and the author (who works at Playdead) has released a new short video recently: