• Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
  • We have made minor adjustments to how the search bar works on ResetEra. You can read about the changes here.

Django.Mango

Member
Jan 31, 2018
802
Maybe this will make things make more sense, this is normally the C64 high resolution mode:

themill_b_npe.png


If you break the image up into 8x8 tiles, you'll notice no square ever uses more than 2 colors:

1440002461491940.jpg


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.

Thanks for this beauti thread and these background explainings. Really appreciating Krejlooc.
 

Hayama Akito

Member
Oct 25, 2017
1,326
The also homebrew Super Cassette Vision port is pretty impressive too. I played it in Japan in 2017 and it looks even better than the latest video.

 

bjork

Member
Oct 27, 2017
887
I love this. I also like that minus world exists, but it's a different minus world stage and has an end.
 

Runner

Member
Nov 1, 2017
2,715
i watched a video recently about someone who literally put a raspberry pi inside an NES cartridge and used it to play super mario world on an NES which this reminded me of
 

P-Tux7

Member
Mar 11, 2019
1,344
This is beautiful. The only bugs I see is some weirdness with hitting bricks; Mario doesn't seem to get bumped down when he hits them, a la the SNES port which did that too.
 

Bleu

Banned
Sep 21, 2018
1,599
Hoo that sprite sheet is from sacrad armour of antiriad, what a nostalgic hit, i'm old, fuck.
 

Deleted member 48897

User requested account closure
Banned
Oct 22, 2018
13,623
This has to be some eldritch magic.

It's a really cool-looking effect, but it's actually pretty simple to explain what's going on there. Since the screen is only scrolling vertically and you can store roughly two TV screens' worth of tilemap in the NES rom, you can just read a line of screen data at a time starting from the top and skip over every X lines at first, then every X-Y lines, then start reading it like a normal map. Offsetting lines up and down like this is a pretty common technique (and you can do similar things if you have a copier or scanner by moving your hand in sync with the scanner beam) to try to move big objects in NES games, like you see in Contra or some Mega Man games; this is just a slightly more elaborate form of that.

Your usual hint for what's going on is that the background over which the big thing is moving is all a single color.
 

low-G

Member
Oct 25, 2017
8,144
Meanwhile on my childhood computer, the TI994a - which came out 1 year before the C64 (or earlier depending on some technicalities)...



(cheating tho...)

 

Deleted member 8468

User requested account closure
Banned
Oct 26, 2017
9,109
Incredible to me how dedicated some groups are to optimize and squeeze better performance out of these old restrictive machines. I'm going to see if I can get this running on my Mister later on.
 

Lord Error

Member
Oct 27, 2017
4,368
Impressive, but not that surprising for me, as I've seen the high res video mode used in some newer game demo examples.

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, Creatures, or the new Sam's Journey.

There are many completely crazy new video modes for C64 that have been figured out over the years, that were never intended to be possible originally - done by using some vblank and scanline interrupt tricks. As for the sprites, there are some incredible sprite multiplexers availabe on C64 now, which provide pretty much flawless, flicker-free numerous sprites.
 
Last edited:

apocat

Member
Oct 27, 2017
10,057
I wish I could go back in time and give my young self this to play on my old C64. Seriously wonderful to see the old breadbox still get some love to this day.
 

eso76

Prophet of Truth
Member
Dec 8, 2017
8,119
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.

.

What about this ? I'm not sure what it's using but it's pretty damn impressive

 
Oct 26, 2017
7,981
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).
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.
 

Fafalada

Member
Oct 27, 2017
3,066
There are 1 pixel horizontal gaps everywhere. Look at the pixel separating the legs of the M in Super Mario Bros, for example.
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%.
 

Lord Error

Member
Oct 27, 2017
4,368
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%.
Looking at it in the emulator now - clouds are high res too, but the rest of the graphics are 'fat'.

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.
Yeah, I think so too - both games actually have multicolor 'fat' pixel for graphics, but Mayhem has high res main character sprite for example.

What about this ? I'm not sure what it's using but it's pretty damn impressive


Forgot about that one! Yes, I played it, and it looks really good. I read posts on the forum where the authors of the game post, and there were people saying at first that it probably just uses static screens with 2-color per block high res mode - but the game actually has scrolling sections too.
 
Last edited:
Oct 26, 2017
7,981
Yeah, I think so too - both games actually have multicolor 'fat' pixel for graphics, but Mayhem has high res main character sprite for example.

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 (like the mountain slopes) but not always, maybe Krejilooc got confused by those square 2x2 pixels?
 
Last edited:

James3D

Member
Oct 25, 2017
1,001
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.

That PC-88 version looks miserable to play.
 

Lord Error

Member
Oct 27, 2017
4,368
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?
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.
 

KDR_11k

Banned
Nov 10, 2017
5,235
What's notable about the scrolling in this? To my untrained eye it looks like any other sidescrolling game. And as others have pointed out it looks like everything is multicolor. Sure, SMB has better graphical design and more refined gameplay than Giana Sisters but what's the technical achievement here?

Mayhem was available on the Wii VC. Unfortunately that's no longer available.
 

neopokekun

Member
Apr 19, 2019
47
Maybe this will make things make more sense, this is normally the C64 high resolution mode:

themill_b_npe.png


If you break the image up into 8x8 tiles, you'll notice no square ever uses more than 2 colors:

1440002461491940.jpg


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.
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.
 

Weltall Zero

Game Developer
Banned
Oct 26, 2017
19,343
Madrid
I have absolutely no clue how the C64 port of SMB is doing it

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:

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.

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.
 
Last edited:

sugar bear

Member
Oct 27, 2017
1,642
I would have played the hell out of this in the late 80s. My C64 died in 1990 and I didn't own an NES for another year or so.
 

Lord Error

Member
Oct 27, 2017
4,368
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.
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!)
 
Last edited:

Lord Error

Member
Oct 27, 2017
4,368
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:

 

KDR_11k

Banned
Nov 10, 2017
5,235
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!)
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.

The c64 can normally only display 8 sprites at once
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.

Most post-black-box NES games use memory mappers (additional chips on the cartridge akin to the Super FX chip on the SNES) or the Famicom Disk System to make the NES more powerful, the stock NES can only scroll in one direction at a time (hence the weirdness in Karnov), for example. A Game Boy is more powerful than a stock NES, only the memory mapper chips make the NES more capable.
 

test_account

Member
Oct 25, 2017
4,645
Amazing! I wad aldo surprised to hear how the music is identical. Is there any information on how they did the music? One channel for basd and drums combined and the two others for the main melody?
 

Pottuvoi

Member
Oct 28, 2017
3,064
Yu
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:


Yup, that is amazing.


Eye of the Beholder is also looking good.