It is currently Wed May 22, 2019 1:36 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 32 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Sat May 04, 2019 11:08 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4172
zzo38 wrote:
ccovell wrote:
Home computers (/ old IBM PCs) that didn't have any fine scrolling regs in hardware had to manually shift the entire screen data around to get any kind of scrolling. Which is why many games either had choppy scrolling or did it in 8/16 etc pixel increments.
Actually on PC you can do vertical scrolling by tiles (if you have enough video memory), but I don't know if this feature was ever used. Horizontal scrolling is also possible although since the next tile in video memory after the rightmost tile is always the leftmost tile of the next row, the program will still have to deal with the edges of the screen after scrolling since it can't store them in video memory; I don't know if horizontal hardware scrolling was ever used either.


Jazz Jackrabbit might have used it?

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Sat May 04, 2019 11:08 am 
Offline

Joined: Mon Apr 16, 2007 10:07 am
Posts: 121
Bananmos wrote:
I actually learned a new fact about the C64 from this: Apparently the Super Mario port uses "VSP", a hardware quirk that allows you to scroll the entire screen, just like on the NES, by incrementing / decrementing the 3-bit scroll on an exactly timed cycle outside the visible screen. I can imagine that must have been quite useful to port a game that relies so heavily on scrolling...

The downside is it randomly crashes some C64s. Apparently it took a few years until C64 coders worked out that it would always corrupt every 8th byte of memory, and that a possible work-around is to avoid using every 8th byte in your code / data. Quite an awkward work-around and steep price to pay for NES-style scrolling... not sure if the port goes to this extent to avoid crashes, or ignores the existence unfortunate "VSP-unfriendly" C64s? In any case, pretty awesome trick.


A little more detail:

The memory corruption occurs on some C64s because when VSP is triggered (or similar situations) the VIC-II (The C64s PPU) gets a little screwy with its memory refresh cycle. The VIC-II is responsible for DRAM refresh. If I remember correctly, VSP causes the VIC-II to poke the DRAM in such a way that it sometimes triggers a refresh operation in the memory but when this happens the VIC-II's address lines are all over the place. This has the effect of the DRAM seeing a changing address during refresh and the pits from one memory cell can get overwritten with the bits from another.

The thing is, ALL VIC-IIs are effected by this and it is pretty much the minute differences in bus timing and the silicon between models that cause the VSP bug to happen or not.

The easiest way to mitigate this on all C64s is to replace the DRAM with SRAM. My C64 had the VSP bug (but not bad enough to make Mayhem crash) and replacing the DRAM with SRAM fixed it up near perfectly.

_________________
Insert witty sig. here...


Top
 Profile  
 
PostPosted: Sat May 04, 2019 11:21 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8367
Location: Seattle
Dwedit wrote:
Jazz Jackrabbit might have used it?
EGA and VGA (and later in these legacy video modes) all supported fine scrolling (within a character cell, which is 1 to 64 scanlines) as well as coarse scrolling (start of display). What I said last time.

The 6845 in the CGA (and MDA and Hercules) "only" supported coarse scrolling, which in the graphics modes is 8x2 pixels (in 640x200) or 4x2 (in 320x200), and in text mode is one character.


Top
 Profile  
 
PostPosted: Sat May 04, 2019 12:01 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 923
zzo38 wrote:
Actually on PC you can do vertical scrolling by tiles (if you have enough video memory), but I don't know if this feature was ever used. Horizontal scrolling is also possible although since the next tile in video memory after the rightmost tile is always the leftmost tile of the next row, the program will still have to deal with the edges of the screen after scrolling since it can't store them in video memory; I don't know if horizontal hardware scrolling was ever used either.
The IBM CGA and PCjr versions of Boulder Dash managed 60 fps scrolling using the 6845 video controller.


Top
 Profile  
 
PostPosted: Sat May 04, 2019 12:05 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21391
Location: NE Indiana, USA (NTSC)
Pokun wrote:
On the other hand it doesn't have a graphic mode for plotting lines and such that home computers had but games don't really need.

With the exception of things like Qix and Elite.

On EGA or VGA, so long as you have enough memory for about 2.5 screens, you can indeed scroll one plane. That's 2 buffers (front and back), plus at least one metatile's worth of scrolling seam at the right and bottom. This is what Commander Keen does. But you can't scroll more than one plane without doing the same tricks you'd do for parallax on an NES, Master System, or TurboGrafx-16, such as sprites drawn behind the background. Also, wrapping around at the side of the screen isn't trivial because of the linear addressing, but it isn't any more difficult to deal with than the non-power-of-two height of the NES nametables.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Sat May 04, 2019 4:18 pm 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 464
Quote:
Abobo big Adventure won't be on Nintendo's radar since it's not own by them but technos Japan (now defunct and own by Arc System) and isn't a trademark of them either. Super Mario bros, on the other hand, they own.

As to why is Super Mario Crossover was not affected, my guess would be it's a rom hack and not a port of the actual super mario bros game so it does make a difference.


Nah, both of your statements are incorrect. Abobos adventure is a homage to NES games in general, and does include a lot of graphics and gameplay elements from Mario / Zelda / Balloon Fight, as well as an abundance of random Nintendo characters. And a very gory showdown with the main characters from one of Nintendo's recently revived franchises as the final boss fight...

SMC is not a rom hack, but a very faithful Flash recreation of SMB1 (though it allows backtracking), with the added element of being able to play as other videogame heroes (some owned by Nintendo, some by third-party licenses). With the standard Mario/Luigi available thrown in for completion. Not at all unlike the C64 port.

The best explanation I can think of is that Abobos Adventure in particular borders offers protection as parody/satire, but that's honestly a difficult one to argue. It could just be that some people/sites are just unfazed by C&Ds. Either that, or I guess the ways of the Nintendo's legal team are just mysterious... in any case, I'm certainly happy these gems are still accessible year after year.


Top
 Profile  
 
PostPosted: Sat May 04, 2019 4:34 pm 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 464
[url]As far as I know it, on the C64, there are registers for a fine scroll of only 0..7, after which point games normally have to manually shift the entire screen data by 1 column.[/url]

Exactly. The 8-pixel scroll helps a lot, but on an NTSC system in particular, the shifting of the entire screen willl take around half the cycles in a frame and can easily be a bottleneck. And this code is already running on a CPU approximately half the clock speed of the original one the code was written for.

With all the RAM the C64 has, a common technique is to render the next 8-pixel increment scroll early... but if your max scroll speed if 5 pixels or more you could still end up having to do and 8-pixel increment in two consecutive frames...

Not sure how fast SMB1 maximum scroll speed is, but in any case it's easy to see how the VSP trick must have been quite fundamental for getting the C64 port running with only occasional slowdowns. Even if it messes up some C64s. I just checked, and the port does in fact just accept crashes on VSP-sensitive C64s. Feel free to give it a try on yours :)

There is actually a not-too-complex HW mod that completely removes the VSP-related crashes: http://wiki.icomp.de/wiki/VSP-Fix


Top
 Profile  
 
PostPosted: Sat May 04, 2019 8:21 pm 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 103
ccovell wrote:
As far as I know it, on the C64, there are registers for a fine scroll of only 0..7, after which point games normally have to manually shift the entire screen data by 1 column.

Home computers (/ old IBM PCs) that didn't have any fine scrolling regs in hardware had to manually shift the entire screen data around to get any kind of scrolling. Which is why many games either had choppy scrolling or did it in 8/16 etc pixel increments.


The C64 used 1000 bytes to store character data and 1000 bytes of color attributes; an NTSC c64 made about 15,995 cycles/frame available to the CPU. A normal optimized copy loop would be 8 cycles/byte, which doesn't quite leave enough to do full screen scrollilng unless one manages some tricks. If I were trying to create an SMB-style scrolling game based on double-size metatiles, I'd have two tile sets, one of which would place odd numbered character codes on the right, and one of which would put them on the left. Switching character codes would thus implicitly move every other character left by one time without having to rewrite anything, thus cutting in half the number of bytes needing to be rewritten.


Top
 Profile  
 
PostPosted: Sat May 04, 2019 10:09 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2293
Location: Fukuoka, Japan
@Bananmos

I played a few stages of Abobo after replying to this message so they kind of use in "unusual" way some of the character for feeding purpose :lol: There is a few Nintendo characters here and there so satyre would be one possibility. I need to finish it someday (never played it before) and test all the options for the mermaid since eat was the wrong (?) choice :P

For the second game, never played it too, seems was wrong again ^^;; I still think the main point is that both of them are not port of actual games to another system so this may be one reason why Nintendo did nothing about it, or not.


Top
 Profile  
 
PostPosted: Sun May 05, 2019 2:42 am 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 464
supercat wrote:
The C64 used 1000 bytes to store character data and 1000 bytes of color attributes;


Oh yes, I totally forgot about the color attributes. That makes the VSP trick even more crucial for this port.


Top
 Profile  
 
PostPosted: Fri May 17, 2019 12:45 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1348
nesrocks wrote:
8bitMicroGuy wrote:
They should have changed the graphics, music, sound effects and levels to make it more original

Then the internet wouldn't care about it.


This - many talented people can create a mario-esque game, but having this one actually be a faithful port of the original game (within limits) is the (imo) more significant effort that makes it stand out.

Never mind turning this into a Giana Sisters-like game in terms of graphical overhaul - it's the stages and physics that make Super Mario Bros what it is. There are so many rom hacks with new levels, and so many homebrew platformer games that are arguably similar to Mario, but only a tiny sliver of these feature clever and well-designed level layouts. "Just replace the levels" is a statement that overlooks how important level design is.


Top
 Profile  
 
PostPosted: Fri May 17, 2019 1:00 pm 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 103
zzo38 wrote:
ccovell wrote:
Home computers (/ old IBM PCs) that didn't have any fine scrolling regs in hardware had to manually shift the entire screen data around to get any kind of scrolling. Which is why many games either had choppy scrolling or did it in 8/16 etc pixel increments.
Actually on PC you can do vertical scrolling by tiles (if you have enough video memory), but I don't know if this feature was ever used. Horizontal scrolling is also possible although since the next tile in video memory after the rightmost tile is always the leftmost tile of the next row, the program will still have to deal with the edges of the screen after scrolling since it can't store them in video memory; I don't know if horizontal hardware scrolling was ever used either.


I've used the feature myself in a file-viewing program, and there was also a console driver (FANSI.SYS I think) which used it for scrolling of console-based programs that didn't perform memory-mapped screen access. My file viewer could scroll up or down at two lines/frame with no "snow" on a 4.77MHz XT with CGA card, and if memory serves it could scroll left/right at four characters/frame.


Top
 Profile  
 
PostPosted: Fri May 17, 2019 1:56 pm 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 103
Bananmos wrote:
supercat wrote:
The C64 used 1000 bytes to store character data and 1000 bytes of color attributes;


Oh yes, I totally forgot about the color attributes. That makes the VSP trick even more crucial for this port.


Using the even/odd scroll technique would allow the screen to scroll 8 pixels/frame using less than half the CPU time for screen redraws without doing anything exotic. If there are 64 or fewer metatile shapes, copying each metatile left 8 pixels (both character and attribute) would take 26 cycles without any raster splits to assist (5928 total). Using shape raster splits (two interrupts per metatile for a trick known early in the 64's lifetime) could cut that to 24 per tile (5472 total), and FLD raster splits (three interrupts per metatile, using tricks I first saw fairly late in the 64's lifetime) could reduce that to 16 (3648 total). I don't know why VSP should be needed for an SMB-style game when less exotic techniques would cut the CPU overhead to manageable levels.


Top
 Profile  
 
PostPosted: Fri May 17, 2019 8:55 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2293
Location: Fukuoka, Japan
mikejmoffitt wrote:
This - many talented people can create a mario-esque game, but having this one actually be a faithful port of the original game (within limits) is the (imo) more significant effort that makes it stand out.


Faithful port are difficult and sometime you have to decide where you have to make compromise to make it work in the end. That's the hardest part and always have a hard time to make compromise in those case. I won't say why I'm talking about it, need to stop talking.. :lol:


Top
 Profile  
 
PostPosted: Sat May 18, 2019 3:24 pm 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 464
supercat wrote:
Bananmos wrote:
supercat wrote:
The C64 used 1000 bytes to store character data and 1000 bytes of color attributes;


Oh yes, I totally forgot about the color attributes. That makes the VSP trick even more crucial for this port.


Using the even/odd scroll technique would allow the screen to scroll 8 pixels/frame using less than half the CPU time for screen redraws without doing anything exotic. If there are 64 or fewer metatile shapes, copying each metatile left 8 pixels (both character and attribute) would take 26 cycles without any raster splits to assist (5928 total). Using shape raster splits (two interrupts per metatile for a trick known early in the 64's lifetime) could cut that to 24 per tile (5472 total), and FLD raster splits (three interrupts per metatile, using tricks I first saw fairly late in the 64's lifetime) could reduce that to 16 (3648 total). I don't know why VSP should be needed for an SMB-style game when less exotic techniques would cut the CPU overhead to manageable levels.


I think you're missing the point here. The game doesn't have half the screen time or even a quarter to spare - it's already showing significant slowdowns in places, precisely because it is running code that was written for another gaming system, where the 6502 is clocked almost twice as fast.

Yes - as other have pointed out - it's perfectly possible to do a mario-esque game on the C64, and with good coding it's probably feasible to it all with conventional 8-pixels only HW scroll, for greater compatibility. But the point of this port was obviously to make it run the original SMB1 code with all subtle gameplay elements intact, except for the necessary concessions due to the different video/sound hardware.

Making that original SMB1 code (which again, was designed for a CPU clocked almost twice as fast) run on the C64 without introducing even more lag would have required finding some major speed optimization opportunities in the original code. And even if such opportunities were identified, it's highly likely that compromises would need to be made, gameplay would change slightly, and the end product would be a subtly different game.

Personally, I think this port is a beautiful effort, despite having to resort to techniques which lower compatibility. That was one of the sacrifices that were needed to keep the lag down. And to the people who will be running this, I don't think getting either a VSP-friendly C64 model or performing the documented HW mod is out of reach.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 32 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group