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?
A good point -- I mentioned support and coding tools, but the platforms themselves are emulated to excellent accuracy, and the emulators can be automated via scripting to fast-forward execution, inspect and edit live memory, and run practically unlimited numbers of emulators in parallel. So, indeed, PC tools for programming at least, very much viable.
Which, I don't know that there's a whole lot of application to run emulators in parallel, for programming purposes -- perhaps to run a genetic algorithm to solve some especially perplexing optimization problem say? -- but there are other reasons, certainly. If not especially practical reasons.
For example, storing files in an array of Tetris instances (15:10).
The... less exotic application, of course being tool-assisted superplays or speedruns. Some TASs accumulate 100k's of "rerecords" using scripts to brute force routes, button combinations, setups, etc. A "pure" study, in the sense of being entirely for entertainment purposes.
Tim
We're talking 8-bit computers, so 64k memory was maximum.
8...16k would normally be occupied by the "OS" ROM, leaving 48...56k for RAM. I'm aware that some machines used "bank switching" techniques to get around that point, but they were the exceptions.
A good point -- I mentioned support and coding tools, but the platforms themselves are emulated to excellent accuracy, and the emulators can be automated via scripting to fast-forward execution, inspect and edit live memory, and run practically unlimited numbers of emulators in parallel. So, indeed, PC tools for programming at least, very much viable.
I think I mentioned this project a while ago, but here it is:
https://github.com/floooh/chipsit has emulation for a number of classic 8-bit CPUs (Z80, 6502...) and for a number of 8-bit computers (C64, Amstrad CPC, ZX Spectrum...). It's relatively easy to understand, you can use the examples directly or derive your own emulators from them. Pretty cool.
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?
Fair point. Realtime emulators with real-time cross assemblers now exist for the C64 and Atari. We are talking instant and realtime code editing and viewing results. This should help with development and debugging, plus don't forget to add modern graphic paint and music/score software tools.
As for the ram, the Atari examples I illustrated above were 48kb, standard stock.
I'm also guessing modern development teams have dedicated graphics/art, music and coders who have all seen what could be possible.
I guess it boils down to not that it couldn't be done in 1983, but the kind of skill set required by a fluke perfect team sweating it out for a year, op-code by op-code, pixel-by-pixel, note to sound-FX, not even sure at the beginning how the final product would actually look or behave where all that work may end up being a total waste of time and money they probably don't have.
Zippy (Sonic) for the Atari 2600. Well, with only 128bytes of user ram and no authentic graphics or sound hardware, I guess this is as good as it can get:
The VIC on the C64 had a register that would shift the screen horizontally by one pixel. Softscrolling was done by using this register for 7 pixels, then shifting the complete map by 8 pixels (copying the content) and resetting the register to 0.
This register was not latched on vertical blank! That means it could be modified and be effective immediately, for each scanline!
Parallax scrolling is just that technique, combined with a raster interrupt to scroll different horizontal bands at different speeds. You'd also reload e.g. a different color map for each of the bands, or a different character map to allow different graphics. Or you could reprogram the sprites, effectively allowing more than 8.
Obviously those scrolling bands could not overlap, but you could work around that by carefully tweaking the graphics content to make it appear as if they overlapped.
The VIC on the C64 had a register that would shift the screen horizontally by one pixel. Softscrolling was done by using this register for 7 pixels, then shifting the complete map by 8 pixels (copying the content) and resetting the register to 0.
Was the content copied or the frame address incremented and then one column copied?
The VIC on the C64 had a register that would shift the screen horizontally by one pixel. Softscrolling was done by using this register for 7 pixels, then shifting the complete map by 8 pixels (copying the content) and resetting the register to 0.
Was the content copied or the frame address incremented and then one column copied?
Indeed, when scan address registers are available, that's the easy way to do it. Same is true of EGA, hence Carmack's development of Commander Keen. EGA is not sprite based, but it is bit-planed, so shifting the address 1 byte shifts the display 8 pixels left/right, or 40 bytes for one line up/down. And there's a pixel offset register to handle that. Redraw the new rows/columns every 8 pixels, and you've got smooth scrolling with little CPU effort. Keep a list of animated background frames and update those every time to add a little motion to the background, and, sprites still have to be drawn the sucky way: redraw the background over the old position, mask and redraw the sprite in the new position, repeat until done, flip the page buffer.
Oh yeah, a little more complicated with buffering, since you need to redraw from the state two frames ago. Worst case, twice the scrolling redraw effort, background and sprites about the same.
CGA I think didn't have it? But it's small enough, the PC didn't have too much trouble redrawing the whole screen in one frame, I think.
Tim
The VIC on the C64 had a register that would shift the screen horizontally by one pixel. Softscrolling was done by using this register for 7 pixels, then shifting the complete map by 8 pixels (copying the content) and resetting the register to 0.
Was the content copied or the frame address incremented and then one column copied?
Indeed, when scan address registers are available, that's the easy way to do it. Same is true of EGA, hence Carmack's development of Commander Keen. EGA is not sprite based, but it is bit-planed, so shifting the address 1 byte shifts the display 8 pixels left/right, or 40 bytes for one line up/down. And there's a pixel offset register to handle that. Redraw the new rows/columns every 8 pixels, and you've got smooth scrolling with little CPU effort. Keep a list of animated background frames and update those every time to add a little motion to the background, and, sprites still have to be drawn the sucky way: redraw the background over the old position, mask and redraw the sprite in the new position, repeat until done, flip the page buffer.
Oh yeah, a little more complicated with buffering, since you need to redraw from the state two frames ago. Worst case, twice the scrolling redraw effort, background and sprites about the same.
CGA I think didn't have it? But it's small enough, the PC didn't have too much trouble redrawing the whole screen in one frame, I think.
My experience at the time was with the Apple 2, which had a fixed frame buffer like CGA, and the Atarti 800, which used a display list processor so could operate like I described to implement smooth scrolling in any direction. I never got into the details of the C64.
The VIC on the C64 had a register that would shift the screen horizontally by one pixel. Softscrolling was done by using this register for 7 pixels, then shifting the complete map by 8 pixels (copying the content) and resetting the register to 0.
Was the content copied or the frame address incremented and then one column copied?
I don't know how game "engines" did it. The VIC only had one register for the start address of the whole linear framebuffer. With some clever programming, I guess you could do smooth parallax scrolling by just manipulating this address pointer.
I don't know how game "engines" did it. The VIC only had one register for the start address of the whole linear framebuffer. With some clever programming, I guess you could do smooth parallax scrolling by just manipulating this address pointer.
That is how it was done. Changing the start address by a small increment will shift the display horizontally, and changing the start address by a scan line will shift the display vertically. Then only a single scan line or column needs to be written by the processor instead of copying the whole frame buffer like an Apple 2 had to do.
Fascinating how hardware designers were creative back in the days to allow software to do amazing things with very limited CPU power - things that people are still able to exploit even better, 40 years later!
The Amiga ASICs were also a feat of engineering.
The Amiga ASICs were also a feat of engineering.
Yes, the time and place of the Amiga1000 chipset in the mid 80's was a gigantic leap.
Unfortunately, there was no 'true' forward innovation after that point locking the system down to a slow anguishing end. (No, quadrupling the addressable display ram and going up to 8bit planes with an option to double the pixel clock right at the end of Amiga's life wasn't truly moving forward.)
Well, they knew the platform was going to die anyway. IIRC, they were already trying to bet on making compatible PCs.
But that wasn't hugely successful either.
Well, they knew the platform was going to die anyway. IIRC, they were already trying to bet on making compatible PCs.
But that wasn't hugely successful either.
In the early, early, early 90s, when I was doing some contract work for RCS Management (Amiga 68040 accelerator cards), we tried to convince Commodore to make adapt their OS to a PC standard. They laughed and thought their hardware was unstoppable.
The 8-bit 256 color capable Amiga AGA chipset was supposed on the Amiga 3000, but no. The A3000 was also supposed to add a Motorola audio DSP with 32 channel 16 bit sound, but not. The A4000 which had the already too slow AGA chipset was supposed to have the AAA chipset with 32bit graphics & a new Paula for authentic HD floppy drive, better RS232 port, and 16 channel HD audio. But no. Guess where Commodore sunk their hardware engineering time and money. It was a stupid project called CDTV. They were too high on Amiga500 sales with games in Europe and ignored the prospect of becoming a competitor to Windows or Mac and let everything slip away.
I don't know all details of the whole story, but I think there was kind of an internal war inside Commodore between those willing to push the Amiga platform and those willing to make PCs. That kind of killed Commodore eventually. But AFAIR, they did make PCs and they did also sell cards for Amigas (2000+) with a 8086 to make them PC-compatible.
Apple had this kind of internal war too between the Apple II line and the Mac. While betting on the Mac was, for the long term, a wise choice, they didn't handle the strategy all that well either. They almost went bankrupt.
Amiga platform and those willing to make PCs.
Just to be clear, we (being RCS management at the time) never recommended to Commodore to make PCs. We wanted them to get completely out of hardware and translate Amiga OS to an x86 cpu.
In the early, early, early 90s, when I was doing some contract work for RCS Management (Amiga 68040 accelerator cards), we tried to convince Commodore to make adapt their OS to a PC standard. They laughed and thought their hardware was unstoppable.
The 8-bit 256 color capable Amiga AGA chipset was supposed on the Amiga 3000, but no. The A3000 was also supposed to add a Motorola audio DSP with 32 channel 16 bit sound, but not. The A4000 which had the already too slow AGA chipset was supposed to have the AAA chipset with 32bit graphics & a new Paula for authentic HD floppy drive, better RS232 port, and 16 channel HD audio. But no. Guess where Commodore sunk their hardware engineering time and money. It was a stupid project called CDTV. They were too high on Amiga500 sales with games in Europe and ignored the prospect of becoming a competitor to Windows or Mac and let everything slip away.
IMO the hardware was the secret sauce that made the Amiga what it was, I'm not sure the OS would have been all that spectacular on standard PC hardware of the era. The problem I see is they either sat on their laurels or spread their resources too thin and didn't keep updating the custom chips at a sufficient rate. The Amiga custom chipset was way, way out ahead when it first appeared, but it didn't really progress all that much over the next 5 years or so and at that time 5 years was an eternity in PC development.
Amiga platform and those willing to make PCs.
Just to be clear, we (being RCS management at the time) never recommended to Commodore to make PCs. We wanted them to get completely out of hardware and translate Amiga OS to an x86 cpu.
That's interesting.
Amiga OS is still being maintained:
https://en.wikipedia.org/wiki/AmigaOS_4(but targets PowerPC now.)
In the early, early, early 90s, when I was doing some contract work for RCS Management (Amiga 68040 accelerator cards), we tried to convince Commodore to make adapt their OS to a PC standard. They laughed and thought their hardware was unstoppable.
The 8-bit 256 color capable Amiga AGA chipset was supposed on the Amiga 3000, but no. The A3000 was also supposed to add a Motorola audio DSP with 32 channel 16 bit sound, but not. The A4000 which had the already too slow AGA chipset was supposed to have the AAA chipset with 32bit graphics & a new Paula for authentic HD floppy drive, better RS232 port, and 16 channel HD audio. But no. Guess where Commodore sunk their hardware engineering time and money. It was a stupid project called CDTV. They were too high on Amiga500 sales with games in Europe and ignored the prospect of becoming a competitor to Windows or Mac and let everything slip away.
IMO the hardware was the secret sauce that made the Amiga what it was, I'm not sure the OS would have been all that spectacular on standard PC hardware of the era. The problem I see is they either sat on their laurels or spread their resources too thin and didn't keep updating the custom chips at a sufficient rate. The Amiga custom chipset was way, way out ahead when it first appeared, but it didn't really progress all that much over the next 5 years or so and at that time 5 years was an eternity in PC development.
The hardware features certainly were the "wow" factor that made the Amiga look spectacular in ads. But, the OS with its preemptive multitasking at the time was leaps and bounds ahead of everything else that was available on other platforms. I remember the pain switching between Windows 3.11 and AmigaOS. But Commodore made the same mistake as every other hardware driven company, trying to wow the customer with hardware bling and not realizing that the software is of equal importance.
In the early, early, early 90s, when I was doing some contract work for RCS Management (Amiga 68040 accelerator cards), we tried to convince Commodore to make adapt their OS to a PC standard. They laughed and thought their hardware was unstoppable.
The 8-bit 256 color capable Amiga AGA chipset was supposed on the Amiga 3000, but no. The A3000 was also supposed to add a Motorola audio DSP with 32 channel 16 bit sound, but not. The A4000 which had the already too slow AGA chipset was supposed to have the AAA chipset with 32bit graphics & a new Paula for authentic HD floppy drive, better RS232 port, and 16 channel HD audio. But no. Guess where Commodore sunk their hardware engineering time and money. It was a stupid project called CDTV. They were too high on Amiga500 sales with games in Europe and ignored the prospect of becoming a competitor to Windows or Mac and let everything slip away.
IMO the hardware was the secret sauce that made the Amiga what it was, I'm not sure the OS would have been all that spectacular on standard PC hardware of the era. The problem I see is they either sat on their laurels or spread their resources too thin and didn't keep updating the custom chips at a sufficient rate. The Amiga custom chipset was way, way out ahead when it first appeared, but it didn't really progress all that much over the next 5 years or so and at that time 5 years was an eternity in PC development.
The hardware features certainly were the "wow" factor that made the Amiga look spectacular in ads. But, the OS with its preemptive multitasking at the time was leaps and bounds ahead of everything else that was available on other platforms. I remember the pain switching between Windows 3.11 and AmigaOS. But Commodore made the same mistake as every other hardware driven company, trying to wow the customer with hardware bling and not realizing that the software is of equal importance.
Most smaller computer platforms were bound to fail, once IBM clones became cheap and widely available. A few hung around afterwards, but not with a significant market share.
In the early, early, early 90s, when I was doing some contract work for RCS Management (Amiga 68040 accelerator cards), we tried to convince Commodore to make adapt their OS to a PC standard. They laughed and thought their hardware was unstoppable.
The 8-bit 256 color capable Amiga AGA chipset was supposed on the Amiga 3000, but no. The A3000 was also supposed to add a Motorola audio DSP with 32 channel 16 bit sound, but not. The A4000 which had the already too slow AGA chipset was supposed to have the AAA chipset with 32bit graphics & a new Paula for authentic HD floppy drive, better RS232 port, and 16 channel HD audio. But no. Guess where Commodore sunk their hardware engineering time and money. It was a stupid project called CDTV. They were too high on Amiga500 sales with games in Europe and ignored the prospect of becoming a competitor to Windows or Mac and let everything slip away.
IMO the hardware was the secret sauce that made the Amiga what it was, I'm not sure the OS would have been all that spectacular on standard PC hardware of the era. The problem I see is they either sat on their laurels or spread their resources too thin and didn't keep updating the custom chips at a sufficient rate. The Amiga custom chipset was way, way out ahead when it first appeared, but it didn't really progress all that much over the next 5 years or so and at that time 5 years was an eternity in PC development.
The hardware features certainly were the "wow" factor that made the Amiga look spectacular in ads. But, the OS with its preemptive multitasking at the time was leaps and bounds ahead of everything else that was available on other platforms. I remember the pain switching between Windows 3.11 and AmigaOS. But Commodore made the same mistake as every other hardware driven company, trying to wow the customer with hardware bling and not realizing that the software is of equal importance.
Most smaller computer platforms were bound to fail, once IBM clones became cheap and widely available. A few hung around afterwards, but not with a significant market share.
Like I said:
Amiga platform and those willing to make PCs.
Just to be clear, we (being RCS management at the time) never recommended to Commodore to make PCs. We wanted them to get completely out of hardware and translate Amiga OS to an x86 cpu.
That's interesting.
Amiga OS is still being maintained: https://en.wikipedia.org/wiki/AmigaOS_4
(but targets PowerPC now.)
We began a 32bit video card project with RCS management. At this time, the SoundBlaster 16 came out with CD quality audio and we saw data sheets for the next generation of GPUs from S3 and Trident (bought/became Nvidia) with their geometry 2D and 3D capabilities as I clearly remmeber being told and asking WTF are Z-buffers. Most of the Amiga blitter functions could be emulated / translated while tons of new graphics functions the Amiga couldn't dream of were only a few years away. The Amiga OS was lean, memory efficient and had a community of fans, and if Commodore listened to us, their OS would have run circles around Windows at the time with X86 just beginning to pass 50MHz. Commodore didn't have a clue AGP and 75-125 Mhz CPUs were coming which would trample their hardware, albeit a more expensive in the beginning, but for how long?
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.
Here's the original Master System version. As you can see the C64 port has fewer colours and a slightly lower resolution. I think the Game Gear version was used, which is exactly the same as the Master System, but a lower resolution.
Yes, the C64 can only do 16 colors. I don't think there is even a palette.
Also, I think the C64 tops out at 320x200.
We began a 32bit video card project with RCS management. At this time, the SoundBlaster 16 came out with CD quality audio and we saw data sheets for the next generation of GPUs from S3 and Trident (bought/became Nvidia) with their geometry 2D and 3D capabilities as I clearly remmeber being told and asking WTF are Z-buffers. Most of the Amiga blitter functions could be emulated / translated while tons of new graphics functions the Amiga couldn't dream of were only a few years away. The Amiga OS was lean, memory efficient and had a community of fans, and if Commodore listened to us, their OS would have run circles around Windows at the time with X86 just beginning to pass 50MHz. Commodore didn't have a clue AGP and 75-125 Mhz CPUs were coming which would trample their hardware, albeit a more expensive in the beginning, but for how long?
VLB and soon after PCI provided a huge increase in video performance a few years before AGP.
My memory is a bit hazy but it seems like there were several attempts to resurrect the Amiga but excessively restrictive licensing of the OS and other aspects always resulted in attempts dying on the vine. I think the only hope was to open up the OS or at least license it and any of the technology very cheaply and easily in order to get the ball rolling. Even so it was hopless once Windows reached critical mass.