Author Topic: Pushing the limits of original 8bit computers with modern programming techniques  (Read 4668 times)

0 Members and 1 Guest are viewing this topic.

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 6837
  • Country: ca
Pushing the limits of original 8bit computers with modern programming techniques, example 1, a Commodore C64 running an entire Sonic the Hedgehog game.  This runs on original hardware with the requirement of a 256k expansion board which was available from Commodore at the time: (PAL version)



I find it amazing that they got the fluid motion of this 16bit game with all the music included.
With modern knowledge, I wonder what could have been achieved on the Atari 8 bit computer, or even an Atari 2600.
 
The following users thanked this post: Shock

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 14749
  • Country: us
  • DavidH
These system, but not the 2600 as much, had considerable help from a display list processor which allowed smooth scrolling and hardware sprites.
 

Online ebastler

  • Super Contributor
  • ***
  • Posts: 4398
  • Country: de
Looks like a very nice implementation of the game. It is a port of Sega's version for the Sega Master System though, which is also an 8 bit machine (Z80-based).

I am surprised that this game is apparently available for free -- with Sega's blessing? The C64 implementation uses the original names and graphics, which must still be copyrighted and which Sega continues to commercialize. The C64 developers can't be paying royalties to Sega and then giving the game away for free. So has Sega decided to be generous here, given the limited number of C64 systems still in active use?
 
The following users thanked this post: wraper

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 1914
  • Country: nl
What do you mean with "modern programming techniques"?

The CPU they run this on is the same as it was back then and there were also very good programmers at that time, so what techniques are you referring to? Is there a mention in the video, which I have to confess I did not watch to the end?

As an assembler programmer myself, at least in that era, I also wrote specific code for the 6502 that had to be timed to the microsecond which meant trimming every unnecessary instruction.

Offline thinkfat

  • Supporter
  • ****
  • Posts: 2052
  • Country: de
  • This is just a hobby I spend too much time on.
    • Matthias' Hackerstübchen
If you look at the C64 demo scene way back then and what they pulled off, it is not really all that surprising.

That particular game probably makes heavy use of the VIC raster interrupt, custom character sets and sprites, which kind of explains the requirement for 256k of memory.
Everybody likes gadgets. Until they try to make them.
 

Online wraper

  • Supporter
  • ****
  • Posts: 14772
  • Country: lv
find it amazing that they got the fluid motion of this 16bit game with all the music included.
With modern knowledge, I wonder what could have been achieved on the Atari 8 bit computer, or even an Atari 2600.
While it's very impressive this running on C64, it's not even close to original game for genesis/mega drive.
 

Offline Phil_G

  • Regular Contributor
  • *
  • Posts: 53
  • Country: gb
  • G4PHL
I'd suggest that 'modern programming techniques' produce bloated & wasteful code compared the cycle counted assembler we used back then (still do in my case, I'm a bit of a dinosaur)
Todays 'optimising compiler' isnt a match for a good 1980s machine code programmer [light blue touch paper and retire immediately]
 
The following users thanked this post: alank2, SL4P, neil555, james_s, pcprogrammer

Online Zero999

  • Super Contributor
  • ***
  • Posts: 17447
  • Country: gb
  • 0999
find it amazing that they got the fluid motion of this 16bit game with all the music included.
With modern knowledge, I wonder what could have been achieved on the Atari 8 bit computer, or even an Atari 2600.
While it's very impressive this running on C64, it's not even close to original game for genesis/mega drive.
That's because it's the Master System version. A different game, made for an 8-bit system. The levels are smaller, some are completely different and there's no parallax scrolling, as it didn't have the hardware to do it. Some features were removed: Sonic couldn't pickup the rings, after losing them, probably because the system didn't have enough sprites, the maximum number of rings he could have was 99, presumably because it avoided the need for integers longer than a word.
 

Online MathWizard

  • Frequent Contributor
  • **
  • Posts: 575
  • Country: ca
This reminds me of when the guys were making wolfenstein 3d, and they made a homebrew version of NES Marioworld, but IDK what PC they were on back then....probably not a C64, I think it might have been something cutting edge at the time.
« Last Edit: June 21, 2022, 04:43:54 am by MathWizard »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 6837
  • Country: ca
I'd suggest that 'modern programming techniques' produce bloated & wasteful code compared the cycle counted assembler we used back then (still do in my case, I'm a bit of a dinosaur)
Todays 'optimising compiler' isnt a match for a good 1980s machine code programmer [light blue touch paper and retire immediately]
Maybe you guys are misunderstanding what I mean by modern coding techniques.  I don't think that these new game releases are programmed in 'C' language.  I'm sure they were written in assembly.  Maybe I should have said modern game style, but, I'm sure a number of assembly coding techniques just couldn't be imagined back then.

Here is another example, Yomp for the Atari 8bit computers:



It's a 48k game.  But why did we never never seen anything like this back in 1982 when the Atari 800 already came with 48k ram...

Instead, we got this slow motion junk:



What I would have given for someone to program this one back in the day:




« Last Edit: June 21, 2022, 05:05:21 am by BrianHG »
 

Online Zero999

  • Super Contributor
  • ***
  • Posts: 17447
  • Country: gb
  • 0999
I'd suggest that 'modern programming techniques' produce bloated & wasteful code compared the cycle counted assembler we used back then (still do in my case, I'm a bit of a dinosaur)
Todays 'optimising compiler' isnt a match for a good 1980s machine code programmer [light blue touch paper and retire immediately]
Maybe you guys are misunderstanding what I mean by modern coding techniques.  I don't think that these new game releases are programmed in 'C' language.  I'm sure they were written in assembly.  Maybe I should have said modern game style, but, I'm sure a number of assembly coding techniques just couldn't be imagined back then.
I haven't watched the other videos, but the one you first posted is identical to the Sega Master System Sonic game. It's not the game which would have been modified, but the C64.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 6837
  • Country: ca
I haven't watched the other videos, but the one you first posted is identical to the Sega Master System Sonic game. It's not the game which would have been modified, but the C64.
I saw another video with a Sonic enthusiast who did a side by side comparison.
For the PAL versions, the character movements, timing and screen position was a dead perfect match.
Comparing the NTSC versions, the C64 played a little too fast, and had a glitch bug on some later levels around the water falls / collapsing bridges.
 

Offline thinkfat

  • Supporter
  • ****
  • Posts: 2052
  • Country: de
  • This is just a hobby I spend too much time on.
    • Matthias' Hackerstübchen
I haven't watched the other videos, but the one you first posted is identical to the Sega Master System Sonic game. It's not the game which would have been modified, but the C64.
I saw another video with a Sonic enthusiast who did a side by side comparison.
For the PAL versions, the character movements, timing and screen position was a dead perfect match.
Comparing the NTSC versions, the C64 played a little too fast, and had a glitch bug on some later levels around the water falls / collapsing bridges.


That was on the "retrobits" youtube channel, I think. I saw it, too.
Everybody likes gadgets. Until they try to make them.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 18298
  • Country: us
When I think "modern programming techniques" I tend to think bloated, slow, form over function.

In the case of most vintage systems, games gradually got better and better as new ideas were developed and programmers learned more about the workings and quirks of the hardware. At some point it plateaued and there simply wasn't much more you could make it do. I think the demoscene is probably the best you're going to find, but most demos are using every ounce of computing power available to display the demo, there's nothing left to make a functional game with the same sort of graphics and sound.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 6837
  • Country: ca
When I think "modern programming techniques" I tend to think bloated, slow, form over function.

In the case of most vintage systems, games gradually got better and better as new ideas were developed and programmers learned more about the workings and quirks of the hardware. At some point it plateaued and there simply wasn't much more you could make it do. I think the demoscene is probably the best you're going to find, but most demos are using every ounce of computing power available to display the demo, there's nothing left to make a functional game with the same sort of graphics and sound.

That 3D third person Atari 800 Space Harrier I linked to above shows that such things are possible.
The demo scene do come up with some cool and interesting stuff, but it's nothing like a full game.
« Last Edit: June 21, 2022, 07:39:50 am by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 6837
  • Country: ca
I haven't watched the other videos, but the one you first posted is identical to the Sega Master System Sonic game. It's not the game which would have been modified, but the C64.
I saw another video with a Sonic enthusiast who did a side by side comparison.
For the PAL versions, the character movements, timing and screen position was a dead perfect match.
Comparing the NTSC versions, the C64 played a little too fast, and had a glitch bug on some later levels around the water falls / collapsing bridges.


That was on the "retrobits" youtube channel, I think. I saw it, too.

Apparently, the C64 has Sega's 'Blast ProcessingTM', 7 years before Sega invented it...
 

Offline thinkfat

  • Supporter
  • ****
  • Posts: 2052
  • Country: de
  • This is just a hobby I spend too much time on.
    • Matthias' Hackerstübchen
I haven't watched the other videos, but the one you first posted is identical to the Sega Master System Sonic game. It's not the game which would have been modified, but the C64.
I saw another video with a Sonic enthusiast who did a side by side comparison.
For the PAL versions, the character movements, timing and screen position was a dead perfect match.
Comparing the NTSC versions, the C64 played a little too fast, and had a glitch bug on some later levels around the water falls / collapsing bridges.


That was on the "retrobits" youtube channel, I think. I saw it, too.

Apparently, the C64 has Sega's 'Blast ProcessingTM', 7 years before Sega invented it...

If you refer to linking the scanline interrupt to a DMA transfer, that's indeed a neat trick made possible by the DMA controller on the REM. Changing color palette or character data in the horizontal blanking interval was a trick that was heavily used in demos on the C64, or to do some parallax scrolling in games.
Everybody likes gadgets. Until they try to make them.
 

Online Zero999

  • Super Contributor
  • ***
  • Posts: 17447
  • Country: gb
  • 0999
Blast Processing was just Sega's marketing wank. It didn't mean anything. It also applied to the Genesis/Mega Drive, not the Master System.

I think most Americans seem to lack knowledge of the Master System because it wasn't very popular in the US. It was very popular in the UK and much of Europe. It was very similar to the Game Gear, Sega's portable console.
« Last Edit: June 21, 2022, 10:59:40 am by Zero999 »
 

Offline precaud

  • Frequent Contributor
  • **
  • Posts: 682
  • Country: us
    • LinearZ
Maybe you guys are misunderstanding what I mean by modern coding techniques.  I don't think that these new game releases are programmed in 'C' language.

I don't recall there being a C compiler for 6502 back in the day. Was there?
 

Online Zero999

  • Super Contributor
  • ***
  • Posts: 17447
  • Country: gb
  • 0999
I haven't watched the other videos, but the one you first posted is identical to the Sega Master System Sonic game. It's not the game which would have been modified, but the C64.
I saw another video with a Sonic enthusiast who did a side by side comparison.
For the PAL versions, the character movements, timing and screen position was a dead perfect match.
Comparing the NTSC versions, the C64 played a little too fast, and had a glitch bug on some later levels around the water falls / collapsing bridges.


That was on the "retrobits" youtube channel, I think. I saw it, too.

Apparently, the C64 has Sega's 'Blast ProcessingTM', 7 years before Sega invented it...

If you refer to linking the scanline interrupt to a DMA transfer, that's indeed a neat trick made possible by the DMA controller on the REM. Changing color palette or character data in the horizontal blanking interval was a trick that was heavily used in demos on the C64, or to do some parallax scrolling in games.
I didn't think the C64 or Master System could really do parallax scrolling. I believe it was possible to achieve such an effect by scrolling different parts of the screen at different rates and use sprites moving more quickly/slowly to accomplish such an effect, but it was nothing compared to the consoles with built-in dedicated hardware.

Interestingly, the Mega Drive/Genesis only had two layers, but it did have the capability to scroll different parts of a layer individually to give the appearance of having many more. Sonic does this on some levels, especially Green Hill Zone.

Another interesting piece of trivia is none of the 8-bit consoles and most of the 16-bit consoles didn't have a frame buffer for most modes. The frames were composed of sprites and tiles, which were generated line by line, frame by frame, by the hardware. Frame buffers didn't become common, until the 32-bit era, which was the largest leap in gaming to have occurred ever.
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 1914
  • Country: nl
Maybe you guys are misunderstanding what I mean by modern coding techniques.  I don't think that these new game releases are programmed in 'C' language.

I don't recall there being a C compiler for 6502 back in the day. Was there?

They did exist for the Apple II: https://www.worthpoint.com/worthopedia/vintage-manx-software-aztec-c65-apple-1812710701

Also found this site: https://www.aztecmuseum.ca/compilers.htm
« Last Edit: June 21, 2022, 02:16:47 pm by pcprogrammer »
 
The following users thanked this post: precaud

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 6837
  • Country: ca
Parallax scrolling:



Remember, even the Space Harrier game I've shown above is way beyond parallax scrolling.
« Last Edit: June 21, 2022, 02:37:01 pm by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 6837
  • Country: ca
Here, an actual complete Atari 8bit game with parallax scrolling:



Damn impressive number of colors, good use of manipulating palette on every other line of video and sprite multiplexing.
« Last Edit: June 21, 2022, 03:00:29 pm by BrianHG »
 

Online T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 19773
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
As far as "modern techniques" are concerned, I don't know that there's been a lot of scientific progress in that sense, and, obviously no one's making tools for such platforms -- at least not anywhere close to the kind of development we have for exponentially more advanced modern systems where that complexity is not only worthwhile (solve more complex problems) but necessary (the machine itself is more complex).

These examples are going to be entirely hand written ASM; or, the critical parts are, at least.  And with possible "racing the beam" graphics engines, the whole game state machine may need consistent execution time, too; these may be extraordinarily fragile systems indeed, and the marvel is at how much can be accomplished, pushing the envelope (of CPU and bus cycles, memory capacity and speed, etc.) as perfectly as possible to the point of the whole thing falling over into a glitchy crashing mess.  This can only be achieved through slowly won, extremely deep understandings of the base systems.  And which is nothing different over the now multi-generational history of these systems.

So what's new?  Just historical perspective, I think.  We have some benefit from more clever code generation tools, but these too are hard-won and bespoke among demoscene circles, and are nothing new; there is room for incremental improvement, however.  (For example, say you have a situation where certain operations need to be completed within some number of cycles, and interleaved perfectly with other operations; a tool could search ever-larger configuration spaces to determine how to optimally divide up and interleave those operations.  Even very poor performing algorithms (exhaustive search?) can be afforded these days, which weren't at all feasible back then; granted, exponential (or worse) execution time is still very much against you, but you can afford another order of magnitude every couple of years -- it's something.

And the other is just, we're more comfortable with games, or GUI interfaces, and what goes for a minimum feature set.  Even kaizo romhacks have gotten more popular -- and less punishing.  As a microcosm, consider the notorious early ones like:
https://www.smwcentral.net/?p=section&a=details&id=16059
to recent ones like:
https://www.smwcentral.net/?p=section&a=details&id=28951
I imagine, due in no small part to the success of Celeste (2018), a precision platformer (on PC, Switch, etc.) that, while extremely challenging, is also extremely gracious to the player, and has a fabulous kicking soundtrack, art style, and story.  It's perhaps the archetype from which precision platformers and kaizos will forever after draw their inspiration, and perhaps, in a sense, a peak the whole genre had been building to, and will forever be changed by.  In short, I think it's fair to draw a line from classic insultingly-punishing romhacks, to this non-hack game, back to romhacks and beyond, in the present and future.

(And, perhaps not even very surprising, there is also celeste.smc: https://www.smwcentral.net/?p=section&a=details&id=29613 )

And I think it's fair to generalize this point, in that we will find many other examples where the same sequence fits.  FPS games were around in a basic sort of way since the mid-late 80s, but were forever changed after Doom (1993), and so on by the Quakes, Unreal, Half Lifes, and beyond.  We can draw a line back to Doom, now that those of us who grew up with it (Hi!) are getting nostalgic for it -- but are looking for something with more shine, complexity, style -- and less unfair mechanics than the classics.  There's a whole subgenre of "boomer shooters" now, imitating the low-poly or paletted pixel-art style of those old games, but remixed with the hindsight of modern games, their ease of use, gentler skill curves, and so on.

And so we can return to the case of something like Sonic: at the same time the series has been going forward by official development (Sonic's been in 3D for decades now, matter of fact), it's also been going backwards, in modding and porting by fans, and indeed new remixes and challenges by them as well -- in fact, an official title even started as a fan project and SEGA liked it so much they picked it up and finished it as a full title: https://en.wikipedia.org/wiki/Sonic_Mania

I can't speak for SEGA legally of course, but they have a history of being quite lenient of fan projects.  Sonic fandom is... notoriously quirky, shall we say.  Good on them for tolerating, even encouraging it, despite how cringy it can be at times.

Which, not to waste a callback -- there's a Sonic mod for Doom, or I guess it's a standalone thing all by itself, just based on the Doom engine, even.

And, needless to say, Doom is the poster child of porting things to unusual platforms; there are precious few on anything 8-bit, though.  It seems to be just complex enough of a pile of algorithms, that there's almost no hope of porting much of it to such platforms, even stripping down the graphics and levels as much as you can.  That said, consider this example:



There's also a clone (not really Doom engine as I understand it, but ground-up new along similar lines?) for Amiga 500, evidently quite a challenge:




For my part, I've put a flat-shaded raycaster (ala Wolf3D, without all the Wolf..) on an AVR:



also a basic DSP effects box, and I've demonstrated a few-MS/s-equivalent time sampling method on one; pushing certain limits of the system, but, granted, nothing as deep and comprehensive as the above examples.

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 10169
  • Country: fr
Owning 256KB of RAM at the time would probably be a bit unusual. This expansion was probably pretty expensive. Lack of RAM played a big role in whatever could be achieved back then.

Apart from the amount of RAM, what kind of modern programming techniques are being used for developing those games? First thing is, I bet developers do not actually develop on real C64's, which would make development much easier and more comfortable. What else? What programming languages are they using?

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf