[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/vr/ - Retro Games


View post   

File: 751 KB, 998x441, commodore 64 box.png [View same] [iqdb] [saucenao] [google]
10486810 No.10486810 [Reply] [Original]

This is simply the ultimate 8-bit gaming machine, nothing else comes close. It had the perfect combination of great graphics, great sound system, plentiful of RAM, low cost, practically flawless.
From Ultima to Castle Wolfenstein, Turrican, X-Out, Pirates, Airborne Ranger... There was virtually everything from every genre you'd ever wished to play. The homebrew scene is alive and thriving to this day, people are still making better and better games for the system. What more could you ask for?

>> No.10486821 [DELETED] 

>>10486810
>What more could you ask for?
Good games, which the NES has unlike the C64

>> No.10486829

What was the c64s answer to mode 7?

>> No.10486835

>>10486829
It's an 8-bit machine, zoom zoom.

>> No.10486836 [DELETED] 

>>10486835
Yeah but what about nintendo?????

>> No.10486837

>>10486835
So it didn’t have one, figures

>> No.10486839 [DELETED] 

>>10486836
The NES didn't have mode 7 either.

>> No.10486843 [DELETED] 

>>10486821
What games? Airborne Ranger beats Metal Gear's ass. It's also refreshing to see a Gradius/Salamander port that moves smoothly and doesn't flicker as shit.

>> No.10486857

>>10486829
It's the VIC-II man. That thing's made of magic.

https://www.youtube.com/watch?v=vX8rI7ur-K0&t=166s

>> No.10486867 [DELETED] 

>>10486810
show me one person who owned a C64 in the 80s and isn't fat and bald now

>> No.10486873 [DELETED] 

>>10486839
NES saved video games. There would not be video games if Nintendo did not save video games with the NES yay Nintendo i love Nintendo! :D

>> No.10486881

If Japanese developers had made they're games for the C64 rather than the NES, the 8-bit era as a whole would have been improved twofold.

>> No.10486886

>>10486881
If my aunt had balls she’d be my uncle

>> No.10486890 [DELETED] 
File: 496 KB, 2048x1190, 387074026_718849883391095_6459743986784334369_n.jpg [View same] [iqdb] [saucenao] [google]
10486890

>>10486867
>NOOOOO WHY DO OLD PEOPLE GET FAT AND BALD
There's Christian Thompson/Retro Recipes on youtube though.

>> No.10486901

>>10486881
Japs didn’t make C64 games because they had their own 8-bit computer called the PC-88

>> No.10486902 [DELETED] 
File: 104 KB, 640x480, Minter.jpg [View same] [iqdb] [saucenao] [google]
10486902

>>10486867

>> No.10486913

>>10486886
Too bad she doesn't, and likewise, too bad gaming kinda sucked during the 8-bit era due to Nintendo's stranglehold on talented developers who were stuck with the futile task of trying to make a decent game with such terrible hardware.

>> No.10486914 [DELETED] 

>>10486890
i consider him fat because i'm gay

>>10486902
so fat they need to hide their flab behind a beard

>> No.10486919

>>10486913
Soulful progressive comment, and I actually agree it would have been cool to see japs on the c64 and amiga unironically. Actually it would have been cool to see them on the speccy too. Now I know what to wish for when AI takes over.

>> No.10486962

>>10486810
Loved River Raid. Few months ago I've randomly decided to read about the game, turns out that the chick who made it became pretty much an overnight multi millionaire. Nowadays she's putting all of that money towards freezing herself and her husband near death so that they can be resurrected in the future. Both of them are turbo atheists, but follow cryogenics like a religion. Realistically they'll get frozen, fifty years from now the company in charge of it will go bankrupt and their bodies will get dumped in a river (protip: happened before), but they'll still pump insane amounts of money into the process hoping for the best. Shit's wild.

>> No.10486983

>>10486829
"Mode 7" wasn't anything special. F-Zero could have been a Spectrum game: https://youtu.be/ZlTiwhYopvE?t=360

>> No.10487028

>>10486881
Without the RAM limitation and ROM production cost the NES had, and the prohibitively high price of Japanese home computers, I think the Japanese video game industry would've been a lot more vibrant indeed. The MSX was too expensive and primitive to be a huge commercial success compared to the Famicom.

>>10486901
It was big, slow, and expensive. Due to the high resolution bitmap screen being its only strength, most devs would make visual novels instead of real games.

>> No.10487035
File: 60 KB, 768x634, darkhorn--realm-of-the-warlords.png [View same] [iqdb] [saucenao] [google]
10487035

>>10486810
Love the 64.

Pic-related was an underrated strategy game. Yes, the controls weren't ideal, but the fact it was even possible at all for four players to play against each other at the same time was pretty cool. And I've never figured out how to get good at the tactical combat, but fortunately you could skip that (apart from the final battle in campaign mode. Maybe one day I'll beat it though.)

>> No.10487078

>>10487035
I just started getting into it with c64 dreams. The amount of games is mind boggling for this system. I genuinely love it, I had zero exposure as a kid was born too late, the first computer my parents had before I was born was an amstrad interestingly enough. They worked and met at Costco and I guess they got an amstrad deal through work, even though they were in Florida at the time.

>> No.10487090

>>10486881
>>10486873
The consoles had an advantage in using ROM cartridges where they could stream data in real time while C64 just had a fixed amount of RAM to load your game into and you could only load more data by pausing for a very slow disk load. You will recall how difficult Maniac Mansion was to develop, they used every last byte of RAM in the computer and still needed more so the 1541's RAM was used as well.

>> No.10487101

>>10487090
i mean technically NES had way less space to work with since there's just 2k of RAM and it can only access ROM in 40k chunks. also you can't do some tricks like self-modifying code commonly used on C64 to conserve space.

>> No.10487115

>ultimate 8bit
>doesn't have ninja gaiden, castlevania, or any japanese-developed games
mmmmm

>> No.10487128

>>10487115
Then again it has Boulder Dash and Lode Runner minus obnoxious chibi graphics/music and mutilated game physics.

>> No.10487134

>>10487101
granted but you can easily switch in graphics sets during blank as most games more advanced than NROM do instead of pausing to load crap from disk

>> No.10487148

>>10487115
>doesn't have ninja gaiden, castlevania
It has Castlevania but it was a sketchy port made by leafs with super-abrasive music.

>> No.10487157

>>10487134
>most games more advanced than NROM
And in plain terms, what does that mean? By chance are you referring to the expansion chips in nearly every single NES game? You aren't trying to compare an expanded NES to a stock C64 are you? That's not very fair. Because once we start including expansion hardware for the C64, guess what the C64 can do?
https://youtu.be/jNOF5uuYDr8?t=698

>> No.10487205

>>10487157
>modern expansion chips that didn't exist in the 80s
Wasn't that like those Atari 2600 homebrews that had an ARM CPU in the cartridge?

>> No.10487210

>>10487205
>>10487157
also NES expansion chips just provided ability to use larger cartridge ROMs they didn't add any extra CPU power or anything else. it's the same as multiload C64 disk game.

>> No.10487216

>>10487205
>modern expansion chips that didn't exist in the 80s
An expansion is an expansion. A lot of those NES chips are from the 90's too. But if you're going to be a pissant about expansions only released in the 80's, then here's one: https://www.youtube.com/watch?v=_Cg8r-VmeMk
Still looks better than NES games.

>> No.10487224
File: 68 KB, 499x599, 499px-Paint'n'Sketch.jpg [View same] [iqdb] [saucenao] [google]
10487224

Mario Paint should've used a C64 style light pen instead of a mouse.

>> No.10487291

>>10487090
To be fair MM was probably not coded in the most efficient way possible (for one thing it uses a scripting engine, it's not assembly language). It has a lot of stuff in it like anti-hacking checks that used additional memory space. I'm sure some Euro C64 experts could come up with a more tight, efficient way to implement the game engine.

>> No.10487435

>>10486810
Atari ST >>>>

>> No.10487445

>>10487435
That's 16 bit

>> No.10487470

>>10487115
It's still the best 8-bit computer, beating even the jap 8-bit computers like the MSX. Only the Famicom/NES can beat it

>> No.10487641
File: 23 KB, 440x288, Atari-800-Computer-FL.jpg [View same] [iqdb] [saucenao] [google]
10487641

>>10486810
It's okay to be wrong Anon.

>> No.10487652
File: 9 KB, 640x400, Game really over.png [View same] [iqdb] [saucenao] [google]
10487652

>>10486901
>play japanese 8-bit computer game
>it's all about beating off
>crashes when you beat off too much
I wish they didn't make games for the PC8*01 series of computers either.

>> No.10487659

>>10487641
nice but also older tech and more limited in a number of ways

>> No.10487686

>>10487360
would be neat to do homebrew port of this on C64

>> No.10487704

>>10487686
Converting Z80 code to 6502 is a royal PITA. A ZX Spectrum port would be way easier as the hardware is much more similar to the MSX. But only on Spectrum 128 so you could have the music playing.

>> No.10487713

>>10487704
You just need the CP/M expansion cartridge which adds an Z80 to the C64

>> No.10487731

>>10487713
>You just need the CP/M expansion cartridge which adds an Z80 to the C64
useless piece of crap that only worked on the very early C64s from 1982. plus CP/M software was all designed for an 80 column screen.

>> No.10487751

https://www.youtube.com/watch?v=HVP1pBU7DFA

Circus Charlie looks rather poor compared to the NES or MSX versions.

>> No.10487759

>>10487751
i would think Konami can port their own game better than some dude with a CC cab and no source code or anything. you have no idea what conditions most of those home computer arcade ports were made under.

>> No.10487772

>>10487751
>>10487759
Still, I can't imagine why they made the background blue when the arcade game had a black background.

>> No.10487789

>>10487090
The C64 has a cartridge slot and while it doesn't stream data in real time, you have 64KB to work with instantly. Also the NES can't stream data without an external hardware, without an external RAM it only does bank switching, and without a mapper chip it can't bank switch either. You too could add a DMA chip into a C64 ROM cartridge and make it run huge games like Sonic, it would've been something cheaper to do than giving a NES cart an external SRAM back in the 80s.

>> No.10487798

>>10487789
almost but the cartridge slot only supports 16k of ROM which is a rather big bottleneck. there were some Ocean carts with bank switching but they just banked the ROM in 16k pieces.

>> No.10487816

>>10487470
>Only the Famicom/NES can beat it
Not with those flickery sprites, clunky motions, and scrolling artifacts. The C64 has cleaner graphics and could render bigger and more numerous sprites.

>> No.10487819

>>10486810
Wow, a bunch of shit games nobody outside of Commodore fanboys have ever heard of and some games which fucking tanked the second they hit a system with real games on it. How will Nintendrones, NECkbeards and Segays ever recover?

>> No.10487832

>>10487819
Although Turrican is a meme, Ultima, Wolfenstein, and Pirates! were major and extremely influential games.

>> No.10487835

>>10487819
>How will Nintendrones, NECkbeards and Segays ever recover?
Those are all post 1985. The C64 was the king of the early 80s. After which those systems got bodied by Amiga.

>> No.10487839

>>10486810
>low cost
Weren’t these things retailing at $500 or more in the 80s? I remember an anon posting Radio Shack circulars on here a while back. That’s fuckin expensive.

>> No.10487848

>>10487839
Only for the first couple of months. The price was cut to $300 by spring 1983 and before long they were down to $150.

>> No.10487856
File: 399 KB, 1758x1270, lRh7zCE.jpg [View same] [iqdb] [saucenao] [google]
10487856

>>10487798
The NES only supports up to 32KB of PRG ROM and 8KB of CHR ROM, so games would've had 16K or 32K PRG pages plus 4K or 8K CHR pages, or an external SRAM (usually 16K-32K) to store the CHR and PRG data on the fly. I would say bankswitching was more complicated on the NES. On the C64 you didn't need to divide the ROM into two types of data, ROM pages could be uniformly 16K, and thanks to the vast amount of RAM you could even compress the data in the ROM cart and decompress it using the CPU, saving the cost of needing more ROM chips. C64 cartridge games were cheaper than NES games thanks to that. It may not have been able to stream ROM data on the fly by default, but using a DMA chip like the one found in Commodore REU you could do it. Hence the Sonic port needed the REU.

>> No.10487858

>>10487832
A series nobody cares about so much that the only topic about it is complaining nobody talks about it, a game nobody cared about after Doom and a literally who game. Do PC peasants really?
>>10487835
Maybe in the spectacle department, but once you got down to it nobody ever made a game on the Amiga that was actually fun to play. Unless you're that retard who tried to pawn off, what was it, Ambershit, as a "classic".

>> No.10487859

>>10487839
You buy an C64 from Aldi for 299 DM (about 150 USD)

>> No.10487860

>>10487856
>so games would've had 16K or 32K PRG pages
On MMC3 it was 8k pages and this is used extensively by SMB3 and Kirby to switch in object code for different power-ups.

>> No.10487865

>>10487858
Oh great, it's the anti-micro autist again.

>> No.10487872

I will say the NES ports of 1942, Commando, and Arkanoid were definitely inferior to the C64 ports of those games.

>> No.10487873

>>10487078
I really like the Amstrad too. But yeah the library of games for the C64 is so vast. The C64 was the first computer we had when I was a kid, so it holds a special place for me because of that. It was my first foray into messing around with programming too with BASIC, which was really fun since all the hardware could be accessed so directly and simply.

>> No.10487886

>>10487832
And all three of those were also on other computers such as the Apple II series, there's nothing uniquely C64 about those three

>> No.10487896

>>10487860
Well, it had 2x8KB PRG pages + 2x2KB CHR pages + 4x1KB additional CHR pages. It was complicated. Meanwhile on C64 ROM carts you could just store everything in 16K pages, no hassle.

>> No.10487902
File: 16 KB, 512x448, Wizardry 1 NES.png [View same] [iqdb] [saucenao] [google]
10487902

>>10487886
truth be told a large amount of the NES library was ports from something else

>> No.10487907

>>10487886
>there's nothing uniquely C64 about those three
A lot of the Epyx, early LucasArts, Microprose, etc games were designed primarily around C64. Other companies like DataSoft or Broderbund were more Apple II-focused.

>> No.10487908

>>10487886
I can agree about the first two (though the C64 ports of Ultima III and IV were excellent), but Pirates! was developed for the C64 and is the best version of the original non-remake versions.

>> No.10487915

>>10487908
Not that the Ultima games on NES were bad but they were something completely different. NES U3 for example is just Dragon Quest.

>> No.10487916

>>10487902
Ah yes it's the babby mode versions of Wizardy where you can't die of old age if you take too long to finish and it autosaves after each battle you win.

>> No.10487919

>>10487908
>>10487907
A lot of people including Ron Gilbert also rate NES Maniac Mansion as the best version but the C64 had the best atmosphere of all the versions of the game.

>> No.10487925

next to the Master System the C64 has the best version of Gauntlet and i never cared for the NES one

>> No.10487935

>>10486881
Why does Donkey Kong on C64 have all four stages but the NES doesn't?

>> No.10487936

>>10487832
Don't forget Raid on Bungeling Bay, Project Firestarter, Impossible Mission, Infiltrator, MicroProse Soccer, Gunship, Telengard, and so on. C64 had some of the most important and influential games of the retro era, inspiring modern game design conventions.

>>10487886
The C64 ports usually had vastly improved graphics and performance over Apple II.

>>10487641
I have huge respect for the Atari 8-bit. It was great for 2.5D games but not great for scrolling games though. Back in the 80s it's also harder to develop for because the documentation was lacking. Regardless, those who knew how the system worked created absolutely impressive games. Space Raiders is one of the contenders for the most influential game ever made, bar none. The first true 3D gameplay and massive open world in a home system, and it was unbelievably fast and smooth.

>> No.10487937

Unfortunately we live in the world where the Playstation 5 is selling.

>> No.10488002
File: 12 KB, 275x183, dandy.png [View same] [iqdb] [saucenao] [google]
10488002

>>10487925
Dandy for the Atari 800 is better than Gauntlet on any platform. It's the original Gauntlet.

>> No.10488014

>>10487872
the first two are jank and what's wrong with Arkanoid you ask? how about not having the intro sequence so Taito could save $5 (the game has only 16k CHR ROM instead of the normal 32k in CNROM carts). absolute bull.

>> No.10488036
File: 16 KB, 300x188, 300px-Tetris_Titelbild.jpg [View same] [iqdb] [saucenao] [google]
10488036

>>10487872
C64 has the greatest port of Tetris. How could anyone play Tetris without procedurally generated music?

>> No.10488041

>>10487919
plus the NES didn't get Zak McKracken

>> No.10488042

>>10487936
No one outside of Commodore autists have ever heard of or played those games. Stop trying to make games that are worse than shitty Famicom launch titles happen.

>> No.10488054
File: 197 KB, 384x272, Hover Bovver.gif [View same] [iqdb] [saucenao] [google]
10488054

The ultimate boomer game on the ultimate boomer machine.

>> No.10488057

>>10488042
>No one outside of Commodore autists have ever heard of or played those games. Stop trying to make games that are worse than shitty Famicom launch titles happen.
Raid on Bungeling Bay was ported to NES, silly. It was one of the earliest games for the system.

>> No.10488083

>>10488057
And it's an ugly port that lacks the minimap. The scrolling is also nowhere as smooth as the original.

>> No.10488095

>>10488083
>And it's an ugly port that lacks the minimap
Really early release when they only had NROM carts.

https://gb64.com/game.php?id=6175

This lists C64 ROBB as 199 blocks ie. 50k but I don't believe it was really that big, I think that size figure is also counting the crack intro and trainers.

>> No.10488108
File: 54 KB, 768x634, project_firestart.png [View same] [iqdb] [saucenao] [google]
10488108

>>10487936
>Project Firestart
Love this game. And it was like a proto survival horror game to boot.

>> No.10488116

>>10488108
oh yeah that game. it's actually pretty compromised and not what the developers intended because they meant it as an Amiga game but EA wouldn't let them.

>> No.10488127

>>10488116
Sounds like EA being EA as usual.

>> No.10488130

>>10488095
It's a 1985 release so they would only have the 40K NROM cart. You wouldn't be able to make a minimap sort of thing on the NES without an external SRAM, there's only 2KB memory on the system and you would need to manipulate tiles on the go.

>> No.10488147

>>10488127
Early EA was a pretty different beast.
They wanted to treat software like art and make programmers like rock stars.

>> No.10488151

https://gb64.com/game.php?id=4002&d=18

In fact I know it's not because this claims Jumpman Jr. was 19k but that was a 16k cartridge release. The extra 3k of data have to come from the crack intro and whatnot. So I assume ROBB is probably really 40-ish k.

>> No.10488189

>>10488127
>>10488147
They didn't think the Amiga market was big enough to be worth it.

>> No.10488194

>>10488189
Sounds like bullshit.
EA pushed Amiga a lot in the late 80s and were quite influential.

>> No.10488215

>>10488189
Surprised they thought the C64 market was big enough, that late in the US. I'm happy they did though, compromises notwithstanding, it's still a great game.

>> No.10488269

>>10488194
>>10488189
afaik they wanted the game as an exclusive and there was no way it could be profitable on just Amiga sales (surely EA never considered selling it in Europe?)

>> No.10488278

>>10474446
>mod autosaged the Master System thread
Really? Why? It was up for 4 days and we had some interesting discussion in there.

>> No.10488340

>>10488151
Speaking of games that I wish had a NES port.

>> No.10488486

the NES is a fair bit faster than C64, it has a 1.7Mhz CPU instead of 1.3Mhz

>> No.10488513

>>10486810
Should have been called The Commodore VIC-64

>> No.10488546

>>10488486
It doesn't really matter, most 2D games back in the day depended more on the sprites/graphics controller than CPU speed. The NES PPU has more trouble scrolling the screen and managing a high number of sprites than C64's VIC-II. C64 shmup games look faster and smoother than any NES shmup. The Super Mario port on the C64 has just a tiny bit more slowdowns than the NES original, but otherwise it plays just the same.

>> No.10488564
File: 12 KB, 512x448, SMB2.png [View same] [iqdb] [saucenao] [google]
10488564

>>10488546
that's not really true because VIC-II scrolling is painfully slow unless you do hax tricks like VSP scroll (most modern homebrews use VSP because it's much faster).

>move screen two columns
>have to fetch the next row of data
whereas on NES you can move one entire screen before having to get the next row of data.

https://www.nesdev.org/wiki/Mirroring

as explained in here. VSP works like the same way where an entire screen can be shifted. furthermore very few C64 games scroll the entire screen around as it would be far too slow, they usually have a large status bar taking 1/3rd of the screen while NES games that do it are extremely common.

>> No.10488570

>>10488546
>The NES PPU has more trouble scrolling the screen and managing a high number of sprites than C64's VIC-II

It's an apples to oranges comparison because NES has many small sprites and C64 has a few large ones. The former is better for shmups, the latter for platformers.

>> No.10488582

>>10488546
>The Super Mario port on the C64 has just a tiny bit more slowdowns than the NES original, but otherwise it plays just the same.
that didn't have to be the case but the autist insisted on porting the NES code as literally as possible instead of adapting it in a way that was more suited for C64's hardware. he said he did it to prove he could rather than because it was the best or smartest way of doing things.

>> No.10488589

why did C64 have so many cripplingly bad arcade ports? some notable offenders were Pac-Man, Dig Dug, Double Dragon and Galaxian all quite deficient compared to the NES ports of those games.

>> No.10488608

>>10488589
>why did C64 have so many cripplingly bad arcade ports?
Contra (meaning on the contrary, not Contra the game) 1942, Commando, and Ikari Warriors, none of which have exactly outstanding NES ports.

>> No.10488616

>>10488589
I'd think Namco would have been able to port their own games pretty well. Also DD isn't really a "port" of the arcade game but a reimagining that doesn't have the 2 player mode.

>> No.10488625

>>10488608
>two games that were ported by Micronics
That's not even fair.

>> No.10488662

>>10488608
just so you know Ikari Warriors had two different C64 ports. one was the awesome, kickass PAL version and the other was an Amerifat "port" that looks like it was done in Game Maker.

>> No.10488696

>>10488589
Usually source wasn't provided. The rights to publishing japanese games were bought in bulk at tradeshows by western slop houses and then handed off to bedroom coders to slap something together in a matter of weeks.
On the flip side MSX ports tend to be more faithful yet shitter because source WAS provided but the MSX hardware just wasn't up to the task.
There's the famous story of the guy who just walked around a JP trade show with a sign that read (in japanese) I will port your game. And it worked, people at big companies just gave him the rights to make crap Spectrum versions of hit arcade games.

>> No.10488698

>>10488041
Zak would need 512k of ROM to pull off and probably also fail NOA's censorship.

>> No.10488702

>>10488564
VSP is only needed for Sonic speed games with rich background graphics data. Fast scrolling games had existed long before the invention of VSP, they would use other tricks.

https://youtu.be/QhkFF0c-gUo?si=V6YmF27T8q49pexc
https://youtu.be/-z9ICFshX3k?si=a0OWnxtqHif6bXCy
https://youtu.be/UobuozPuWJw?si=ghPOkwvVMGsVy4jf

Programming tricks which were easy to pull off on the C64 because yould move and modify bits around, things you couldn't do on the NES because ROM is static, and I was commenting on how smooth scrolling looks on many C64 compared to the NES.
https://youtu.be/8hBverjpeLs?si=dprrUwscJZ_MO4vM

The NES could scroll entire screens much faster because the console was made to move sprites and tiles around. There's no way hide the scrolling artifacts that make it look clunky though.

>>10488570
The C64 is still able to display more sprites practically because multiplexing tricks could be done better on the VIC-II, and C64's char data could be used for projectiles instead of sprites. There's no flickery graphics in most C64 shmups no matter how many enemies you throw at the player.

>>10488582
I think it's fine. The port only shows how flexible the C64 is. There are better homebrews to play like Sam's Adventure.

>> No.10488717

>>10488570
It's more that the VIC-II was designed to be stable under h-blank changes in a way the PPU wasn't. You could safely and reliably update the sprite table every line if your ASM-fu was strong enough. So while they had the same number of visible sprites per row (8), the C64's were 24 wide (or 48 at double width) but vertically you were able to use as many as your code would allow whereas the NES topped out at 40. And like you said, they were small sprites so most graphics were composed of multiple sprites leading to less real world usage.

>> No.10488726

>>10488717
the NES is really good at bullet hells because of its sprite setup but platformers can be annoying due to scanline limitations

>> No.10488732

>Sierra won't put any of their adventure games on C64 because they don't think it's technically possible
>but it was ok to put KQ1 on the Master System and fucking KQ5 on the NES?
Seriously?

>> No.10488736

>>10488726
Usually on C64 shmups you use char sprites for bullets but they're choppy compared to hw sprites.

>> No.10488738

>>10488589
They could have done much better ports but those were probably made in six weeks by one guy. Also Pac-Man was released on an 8k cartridge so they couldn't fit the intermission screens. That wasn't for technical reasons it was just the publisher being cheap.

>> No.10488750

>>10488732
I believe it wasn't technical but political reasons. Sierra had a massive beef with Commodore since they lost a ton of money on cartridge games in the video game crash. If they could put KQ1 on the Master System in just 128k of ROM they could have pulled off C64 port.

>> No.10488762

>>10488564
The NES had a limitation in that Nintendo only gave you half the tilemap RAM needed for 8-way smooth scrolling. You have to pick either vertical or horizontal orientation for the offscreen map so for the other direction you have to use the same super optimal block copy as the C64. In other words on the C64 you had to do the hard way all the time so you might as well do 8-way.
Nintendo designed the hardware so the cart could provide the missing RAM and a certain pin on the cart indicated to the PPU if it existed and how to map it. Most 8-way scrolling games used such a mapper.
One of the tricks I always wanted to try on the C64 was to update the new tilemap partially every frame and then swap the VIC-II base address on the 8th pixel. Much less CPU time, but I never did get around to finding out if it worked.

>> No.10488763

>>10488717
yeah yeah the PPU displays garbage if you try to access it during active render, we know. even the Mega Drive doesn't like if you try to write to the VDP RAM outside blank, you get white lines on the screen. see Commando for an example of a game that has major graphics glitches because the programming team had no clue what they were doing.

>> No.10488768

>>10488732
They didn't want to bother with long floppy load time. The DOS PCs had plenty of RAM while the C64 REU was unpopular. By the time ROM chips got cheap, C64 had gone out of fashion.

>> No.10488771

>>10488750
One of the disappointing flaws of C64 carts were that there was only 16KB mapped and no standard bank switching system. Ocean were really the only company that put the effort into making proper carts for the C64. For Scierra to make a 128KB cart they probably would have had to R&D their own bank switching and get them manufactured.

>> No.10488773

>>10488564
VSP only works for H scrolling. There is a different trick called line crunching for fast V scroll but it produces some glitches at the bottom of the screen.

>> No.10488780

Also they put the AGI games on the Apple II but they look ugly, have no sound, and are cripplingly slow and missing features due to memory limitations.

>> No.10488787

>>10488771
>One of the disappointing flaws of C64 carts were that there was only 16KB mapped and no standard bank switching system.

I mean, the NES had no standard bank switching either there were about 2,000 different variations of it all creating a major headache for emulator and Flash cart designers (the Gameboy and Master System had one standardized system)

>> No.10488791

>>10488763
The main difference is on the Mega Drive if you work inside h-blank you're okay but on the NES PPU access inside h-blank was iffy too. Complicated by the fact that the NES has no h-blank interrupt as standard. Some mappers had a way to shoehorn one in, but its usage was limited, like you could update the scroll registers so you could get split screen scrolling, but trying to update the sprite table was a no-no. The PPU was an astonishingly buggy piece of hardware. It has registers expressly for updating individual sprites or colors and such but there's basically no real world way to use them without the PPU trashing data.
And that's the difference between the NES and the C64. On the C64 you could batter the VIC-II sideways and it would take it, often doing surprisingly useful things, on the NES if you didn't work very precisely to just the handful of allowed operations at exactly the right time it would just fail.

>> No.10488795

>>10488787
The main difference as I see it is that Nintendo provided a reference mapper design (or 5) that you could use whereas Commodore didn't so Scierra would have had to invent one and that was perhaps a bit outside their wheelhouse.

>> No.10488803

>>10487134
NES Maniac Mansion managed to fit in-game music because they could switch in the sound bank from the cartridge and switch it back out instantly. You couldn't do that on C64. Normally a game (say a typical MMC1 game) is structured like follows:

>$8000-$BFFF
Swappable 16k bank which may contain sound, level, graphics, or object code for the current level/screen
>$C000-$FFFF
Fixed 16k bank containing CPU vectors, DPCM samples, and essential game routines

The game engine cycles through banks as needed. Normally level data is only used when setting a level up, during actual gameplay the object code is switched in and then you switch in the sound during blank, read and play a musical note from it, and switch in the object code bank.

>> No.10488810

>>10488791
>The PPU was an astonishingly buggy piece of hardware
the VIC-II is just as buggy but most of the bugs were useful in some way while PPU bugs are not useful

>> No.10488812

>>10488771
>>10488787
>>10488795
The only reason nobody made cart games for the C64 was it would be too expensive to manufacture. They wouldn't be able to compete with the much cheaper floppy games that had even more content. Ocean was commissioned to make cart conversion of their games for the failed C64GS console, that's the only reason those cart games existed.

>> No.10488823

https://www.youtube.com/watch?v=vwaZZZ__pwI

Lode Runner looks...crude compared to the NES port.

>> No.10488839

>>10488823
Good. Nobody needed chibi graphics and music designed to appeal to Japanese 6 year olds.

>> No.10488845

https://www.youtube.com/watch?v=V-wNbku3CeI

>a cleaning up was all it needed
Amigas are resilient hardware. If that was a breadbin C64 you would have minimum three dead ICs.

>> No.10488847

>>10488823
It was developed in a week by a young inexperienced college student back in 1983. He likely used the same BASIC and assembly codes that were used in the Apple II port of the game, these ports were finished at the same time.

>> No.10488853

>>10488823
>>10488839
>>10488847
Also C64 is not the best way to play LR because of the one button joysticks, you have to face left or right to drill which is annoying.

>> No.10488854

>>10488823
They had two different ports of LR. The full disk version was just like the Apple II, it had 150 levels and an editor. There was also a 16k cartridge version (shown here) with 30 levels and no editor.

>> No.10488860

>>10488791
>but on the NES PPU access inside h-blank was iffy too
You can do that, Indiana Jones and the Last Crusade does hblank palette switches on the title screen and Pirates! uses it for a mid-line CHR table switch to generate the status bar.

>> No.10488863

>>10488860
>You can do that, Indiana Jones and the Last Crusade does hblank palette switches on the title screen and Pirates! uses it for a mid-line CHR table switch to generate the status bar.

In fact what these games actually do is turn off PPU render during the blank. Also Kirby's Adventure does this to display the status bar.

>> No.10488867

>>10488854
>There was also a 16k cartridge version (shown here) with 30 levels and no editor.
The NES Lode Runner was a really early game with the same ROM size but they got in 50 levels+music+scrolling.

>> No.10488872

>>10486810
A trash system with trash games.

>> No.10488874

>>10488867
Because NES LR isn't really 16k, it's 24k (16k PRG+8k CHR) (^:

>> No.10488881
File: 123 KB, 1892x970, c63c.jpg [View same] [iqdb] [saucenao] [google]
10488881

>>10486810
I've recently got the c64c with kung fu flash so I've been limited to cartridge roms. I've been using a compilation called one load which converts a lot of floppy games to cartridge with almost no loading times. I've been playing atari 2600 for the last few weeks so now going onto 64 so remember that this system was active between late atari 2600 and the earlier part of the nes so don't crap on it for not being like 1992 nes games.

https://www.youtube.com/watch?v=qNxJwLujaN8

Just going through random games is great, some have smooth scrolling, other use hi rez while others are pc style adventure games.

>stuff I tried
1942, compares ok to the nes
1943, made it a lot worse somehow
zaxxon nice graphics but ship moves weird, might be pal ntsc thing
720 skateboarding, nice music and you don't notice the low rez on a crt
zx speccy ports often have a nice tune to hum along to
wonderboy, pretty good, controls could be better
a lot of atari conversions like river raid are nice

>my thoughts
surprisingly nes smooth scrolling quality games
no music on too many games
good early arcade stuff like moon patrol
randomly great music
low budget stuff more comparable to atari but can be fun
stuff that beats nes sometimes
feels like a real game machine vs the spectrum
great fun

>>10486829
combining hi rez and low rez while scrolling

>>10488589
c64 had budget games which could often just be single screen games, nes barely had them. They shouldn't be compared, budget c64 games you would just get while at the supermarket.

>>10487936
just going through c64 and there are plenty of good nes like games

>>10488564
c64 seems pretty smooth to me even if not everyone was able to do it, paperboy is perfectly smooth and thats from 1986

>>10486881
a lot of msx conversions were made but they are not perfectly accurate

>>10488738
pac man was way worse than expected, msx version is very close to the arcade. Its only 8k which is just twice the atari 2600 version.

>> No.10488891

>>10488803
Usually the fixed bank on NES games is the last one at the top of the PRG ROM so if you have 128k then it's at absolute addresses 1BFFF-1FFFF. Unless it was Rare and their AxROM which swaps the whole 32k PRG and has no fixed bank, at power on the bank that's swapped in will be random.

>> No.10488894

>>10488881
>1942, compares ok to the nes
NES 1942 is awful, it's easily the worst arcade port on the system and one of the worst games to get a North American release. Thank you Micronics.

>> No.10488901

>>10488881
>msx version is very close to the arcade. Its only 8k which is just twice the atari 2600 version.

https://www.youtube.com/watch?v=HdaN-yq1fe0

I didn't realize how NES Pac-Man is just a copypaste of the MSX. But actually this is 16k, it's not 8k.

>> No.10488906

>>10488901
Galaxian on MSX is 8k. Also the C64 port of that game is terrible. Jesus, this sucks.

https://www.youtube.com/watch?v=ODrUkKkfbZI

>> No.10488909

>>10488906
some guys did a remaster of it. yeah this one needed it. it was probably ported by a 17 year old in three weeks.

>> No.10488912

>>10488901
>>10488906
>only 8k/16k and not + CHR ROM like on NES
Then again Z80 code is smaller so I don't think they could have gotten away with it there.

>> No.10489110

>>10488912
NES ROM sizes work in increments:

>128k PRG+128k CHR offers more space than 128k PRG+CHR RAM
>256k PRG+CHR RAM offers more space than 128k PRG+128k CHR
>256k PRG+256k CHR offers more space than 256k PRG+CHR RAM
>512k PRG+CHR RAM offers more space than 256k PRG+256k CHR

>> No.10489124

>>10489110
It depends on how much program and graphics data you want to store. Some games would also have data duplicates to make bank switching possible.

>> No.10489126

>>10489110
but there's some odd sizes too. a few 128k games have 32k or 64k CHR ROMs but the only 256k game to have a smaller CHR ROM is Bases Loaded which is the only 256k PRG+64k CHR ROM game in existence.

>> No.10489154

>>10489110
>128k PRG+128k CHR offers more space than 128k PRG+CHR RAM
I did some checking and you're right. Games like TMNT that use the former are generally longer than UNROM games which are mostly pretty short.

>> No.10489168

>>10489110
I'm surprised the 256k PRG+CHR RAM config like Maniac Mansion had wasn't used more often. I doubt it was any more expensive than the twin 128k boards.

>> No.10489204

>>10489168
The 2x128k setup was fine for most NES games and offered plenty of space (nobody thought TMNT or SMB2 were short games with only a couple of levels). Also you didn't have to bother with tile compression which is annoying. Usually 256k CHR RAM was used when you had a game like Maniac Mansion that was just a little too big for 2x128k.

>> No.10489215

>>10488912
>>10488901
If you disassemble these MSX ROMs there's no recognizable tile data in there as it's all compressed. Yes the 16k+8k NES carts were more space than a 1x16k MSX cart but that's compensated a little by Z80 code taking 20% less space than 6502 code.

>> No.10489234

>>119535148
I'm pretty sure it's only fixed on UNROM and most ASIC mappers let you swap out $C000-$FFFF although they usually boot with the last 16k of the PRG ROM switched into there.

>> No.10489505

>>10486810
I agree it has the best of American, British and European games. Other 8 bits are either too british like the tape based speccy, or too American like the overpriced appleii. Not to say they are bad, just that the c64 has the best of both plus more.

>> No.10489559

Why do nigtendo kids need to shit up every non tendie discussion?

>> No.10489612
File: 70 KB, 596x800, 9970492-reach-for-the-stars-the-conquest-of-the-galaxy-third-edition-com.jpg [View same] [iqdb] [saucenao] [google]
10489612

>>10489505
don't forget the 'strayan games

>> No.10490027

>>10489559
Inferiority complex from constantly needing to defend shit hardware and games intended for very small children.

>> No.10490224

>>10489204
they didn't use compressed graphics at all on 16-bit consoles outside those SNES games with a compressor chip like Star Ocean. couldn't because you have to be able to stream the graphics into the video memory in real time.

>> No.10490234

>>10489234
MMC1 can be fixed bank or not, MMC3 has one fixed bank. As you said the fixed bank is always the last 16k at the top of the PRG ROM.

>> No.10490261

another important bottleneck nobody's mentioned: the C64's CPU slows down by 20% during active render as the VIC-II has priority over the system bus. it only runs at full speed during blank.

>> No.10490272

>>10490224
>outside those SNES games with a compressor chip like Star Ocean
*Decompressor chip

Star Ocean would have needed 8MB if the graphics weren't compressed. Although one wonders if the time and expense of developing the S-DD1 actually saved them any money versus just using two 4MB mask ROMs.

>> No.10490273

Why am I not allowed to like computer games on this board lol, I enjoy console games too it’s all free it doesn’t matter. It’s not like I’m spending money on any of these, I don’t get why computer games make this board so upset. It’s retro games, not console games. It gets even more ironic when you’re emulating retro consoles on a computer.

>> No.10490281

Yeah it would be neat if there was a NES Zak McKracken but like someone said probably would need 512k ROM (the game took three 170k disk sides on C64) so too expensive.

>> No.10490293

>>10490281
>Yeah it would be neat if there was a NES Zak McKracken but like someone said probably would need 512k ROM (the game took three 170k disk sides on C64)

The game data is only on one disk, the "boot" disk just contains the game engine and is mostly not used. Still agree it would need a pretty large ROM.

>> No.10490323

>>10490273
>Why am I not allowed to like computer games on this board
Because they're not made by a certain company, and any time spent playing computer games is time you could instead be spending sucking the dick of a certain plumber.

>> No.10490326

>>10490281
>>10490293
Famicom Disk System solved the storage cost problem, but it was more prone to piracy than ROM carts and Nintendo was too stingy to accept that.

>> No.10490332

>>10490326
>Famicom Disk System solved the storage cost problem, but
It also stored only 112k per disk.

>> No.10490336

>>10490281
they shoehorned KQ5 into about that much space. had to cut about 75% of the screens in the game but they did it.

>> No.10490345

>>10490336
I estimated that to fit the entire game they would need about 2MB of ROM (which is technically supported by MMC5). The PC game was 7MB however it was also VGA graphics that use more space than NES graphics. Still ridiculously too much.

>> No.10490489

>>10490332
Then it would need 4-5 disks instead of 3. Not a big deal.

>> No.10490538

>>10490332
>>10490489
They did a few FDS games with two disks but nobody ever tried multiple ones because larger ROMs soon obsoleted them.

>> No.10490554

Ever heard of Dough Boy? Rather obscure C64 game that got a Famicom port.

>> No.10490563

why did US C64 games always look and feel so crude and bleepy compared to Euro ones?

>> No.10490608

>>10490538
ROM didn't obsolete the FDS, ROM was expensive and chip shortage got worse in 1988. Nintendo simply decided to cease the production of FDS because they're that much paranoid of piracy.

>> No.10490640

>>10490608
Actually it did because FDS was developed back when mask ROMs were only 32k and Nintendo underestimated how quickly 64k and 128k chips would become available. Switching disks for larger games is also annoying, if you played the bigger multi-disk C64 games you would quickly start hating it.

>> No.10490652

>>10490608
the late 80s chip shortage was also artificial, there wasn't an actual lack of chips. that happened because TI and Micron went to Congress and cried about Japanese competition so they got tariffs placed on Japanese memory components

>> No.10490654

>>10488036
It's not procedurally generated, it's just a 20 minute music composition. Now Ballblazer is procedurally generated.
Also, the Tetris gameplay itself is not so hot on C64.

>> No.10490680

>>10490640
Due to the linear read routine, the load time of the FDS was 12 seconds at most. It was faster than most PS1 games. Larger ROM chips soon became available, but the FDS remained the cheapest format by a huge margin. Plus it only was 3 years after the FDS launch that chip prices started to normalize again. In those 3 years, Nintendo never shipped the FDS outside Japan. Zelda was published outside Japan over a year too late because they refused to do so. Nintendo killed the FDS because they wanted to make money from cartridge production.

>> No.10490684

>>10490563
A lot of US games were Apple II ports or co-developed for the Apple II. While Europe had a big demoscene which helped encourage people to make impressive graphics and music.

>> No.10490706

>>10490684
to be fair they did have the less capable Spectrum and Amstrad in Europe

>> No.10490707

>>10489124
Code duplication is mainly only something you have to do on AxROM since it banks the entire PRG at once.

>> No.10490730

>>10490706
Acsually the problem was that the Apple II and C64 shared a CPU which made it possible to do lazy copypaste jobs of games. They had the same problem in Europe with shittons of Amstrad games being extremely low-effort Spectrum copypaste and of course all the Amiga games that were Atari ST copypaste. In Europe C64 had the advantage of being the only relevant 6502 machine around so there was less chance of that happening.

>> No.10490772

I would also say C64 Bubble Bobble was not a very good port but I think it was like 50k or something while the NES port had 160k ROM and the Master System 256k.

>> No.10490784

>>10490772
>I would also say C64 Bubble Bobble was not a very good port but I think it was like 50k or something
This one surprisingly was made with access to the (uncommented) arcade source code but 50k was too small, I think that was because they were unwilling to do a multiload game. Euro developers seemed to be really afraid of that while US C64 games after the early days were normally always multiload.

>> No.10490798

>>10489154
UNROM can support 64k ROM in which case it would be similiar to Gameboy games like Super Mario Land but no games actually used that ROM size.

>> No.10490812

>>10490798
there was also 256k UNROM but i think only a few games used it

>> No.10490829

>>10490812
For what you paid for a 256k ROM there wasn't much point in not using an ASIC mapper. Also that would be a pretty long game and there would be no way to add PRG RAM on an UNROM cart so you can't have a battery save, you'd need a password.

>> No.10490854

>>10490798
the bad thing about CHR RAM games is the compressed graphics can be slow to unpack. i know Mega Man 1 is really fast and doesn't have pauses between screen transitions but maybe it doesn't even have compressed tiles.

>> No.10490864

Usually you do a RLE system whereby each tile that isn't 00 or FF has a descriptor byte to indicate how many times it's duplicated. This would also apply to C64, Master System, or anything else that might have compressed graphics data.

>> No.10490870

>>10488872
You must be 18 or older to use this website.

>> No.10490876

i don't think i'm picking NES Ghostbusters over the C64 original any time soon

>> No.10491000

>>10490876
I liked that if you didn't owe the bank any money at the end of the game, the bank saw that as reason enough to raise your credit limit increasing your chances of going into debt in the future.

Also that karaoke title screen
https://youtu.be/95L0gRRxs6k?t=106

>> No.10491014

>>10490784
A multiload game on a cassette (the preferred format for C64 games in Europe) is a major pain in the ass.

>> No.10491016

>>10486810
Is it easily to emulate? What kind of shaders should it use? How does it control?

>> No.10491019

>>10486881
Nope gaming would be less popular and would have kicked off much later

>> No.10491032
File: 75 KB, 389x540, 1636679110302.jpg [View same] [iqdb] [saucenao] [google]
10491032

>>10486881
>>10486901
Pic related was programmed by Satoru Iwata

>> No.10491060

>>10491016
So easy you can actually do bare metal emulation which is cool, I recommend looking that up on YouTube if you’re bored. Shaders, whatever you want on retroarch. It controls fine but a lot of games were designed for a joystick, and personally I’ve yet to find a decent USB joystick unless someone else knows of one, all the ones on Amazon seemed bad last time I looked.

>> No.10491080

http://www.zimmers.net/anonftp/pub/cbm/vic20/roms/4k/index.html

which of these would be fun to do a homebrew port of on C64 or NES or whatever other system you choose?

>> No.10491085

>>10491080
>4k
that's more like Atari 2600 shit

>> No.10491125

>>10491060
Keyboards are more precise and faster joysticks

>> No.10491167

>>10491080
First off why would doing ports of silly VIC-20 games be "fun"?

>> No.10491219

>>10490772
NES Bubble Bobble was 160k (128k PRG+32k CHR). The arcade game was about 536k so if you round that off to 640k and divide by four you reach 160k (the ROM size isn't even so it's probably 640k and some of the space was empty). Perhaps that was how they arrived at the ROM size for the NES port, amusing as it sounds.

>> No.10491225

>>10491219
what a pity BB never got a Mega Drive port considering it wouldn't even need much ROM, it wasn't a 3 or 4MB game that would be too expensive until the mid-90s unless they severely chopped the ROM size down like with Ghouls 'n Ghosts.

>> No.10491372

>>10491342
really? almost 60k for a game that simple? can any of the programming x-perts in here explain why that was?

>> No.10491405

>>10491372
PCs have bitmap graphics which are relative space hogs compared to tile graphics and IIRC x86 machine language is not very space-efficient, some instructions take up to eight bytes of memory while all 6502 and Z80 instructions are 1-3 bytes.

>> No.10491418

>>10491405
>Z80 instructions are 1-3 bytes.
The 8088 that was probably used to run Digger is a lot closer to the z80 than you seem to think. They have almost the same instruction set.

>> No.10491440

>>10491405
>>10491418
I disassembled it and found that the code portion is almost 37k although there's also quite a bit of unused space in the executable. Although most 8086 instructions are 1-3 bytes what happens is when you start doing indirect indexed addressing they get a lot longer.

>MOV [BX+12Ch],5F30h
etc. that takes five bytes. one for the MOV instruction itself then another four for the 12Ch and 5F30. optionally you may put a segment overrider ahead of it like ss:, ds:, etc which is another byte since the BX register assumes the ES segment by default.

>> No.10491445

>>10486829
the C64 actually has built-in sprite scaling from what i recall

>> No.10491449

>>10491445
oh, and i like the C64 but
>that disk drive bug

>> No.10491476

>>10486857
That running bit looks exactly like Hawkeye.
i like c64 tunes as much as the next man but do they really all have to do that blurbblurbblurb sound? The chip is capable of so much more than that shit.

>> No.10491512

>>10487078
Amstrads are a bit pikey

>> No.10491519

>>10491440
and 68000? i'm not so familiar with that.

>> No.10491539

>>10490772
The c64 bubble bobble is a great game.

>> No.10491541

>>10491519
68000 instructions take 1-5 bytes. You can do 8 and 16 bit operands with instructions but JMP/JSR are always 32-bit even though the original 68k can't address a memory location above 16FFFF.

>> No.10491548

>>10491405
The c64 supports bitmaps, but games are typically character based mostly equivalent to tiles.

>> No.10491562

>>10491080
Some fun games there amok and bewitched, terraguard all good. Mosquito infestation could do with a higher res version though.

>> No.10491576

>>10486881
Half of the early vic20 and max cart games were programmed by HAL in Japan.

>> No.10491592

>>10491405
>>10491548
Was like that on the Apple II as well where you had space-consuming bitmap graphics and also the graphics page itself occupied 6k which was a rather large amount of memory for an 8-bit machine. That's why many Apple II games were over twice as big as C64 or Atari 8-bit ones. What could be done on the Atari in 16k would take in excess of 30k on the Apple II. The character screen on C64 however was 1k and each complete set of 256 characters occupied just 2k.

>> No.10491598

>>10491592
the ZX Spectrum was also bitmaps though and it has many quite small games; the early machines only had 16k of total memory.

>> No.10491640

ok

>> No.10491641

>>10491592
>>10491598

All of these systems had DNA from very low ram architectures. This is how the vic20 could have a decent game with graphics and sound in 5k.

>> No.10491665
File: 253 KB, 480x360, ultima iii.png [View same] [iqdb] [saucenao] [google]
10491665

>>10491598
The Spectrum also had a 6k bitmap page and like all bitmap setups of this period it's not linear and slightly convoluted to figure out due to technical issues with addressing the video memory. However the Z80 generally made your life easier than the 6502.

https://www.xtof.info/hires-graphics-apple-ii.html

The Apple II's HGR page is not only non-linear but graphics are stored in reverse of how they're seen on the screen. So you actually have something like this.

>> No.10491741

>>10491449
C64 disk drive is objectively shit. It's an obsolete hardware from the commodore pet era because they wanted backwards compatibility. Definitely the weakest link in the C64 setup.

>> No.10491749

>>10491445
Not technically, but you could modify sprites on the fly, and even add self modifying codes to save processing time. The large sprite rendering size also helps. NES couldn't do anything like that.

>> No.10491758

>>10486983
It's easier to be done on Mode 7 hardware because it's basically a fast matrix multiplication calculator. The Spectrum needs pre-calculated values stored in lookup tables to do the same thing, but at least the bitmap is fast enough to render transformed graphics. The SNES has no bitmap aside from the Mode 7 background graphics, but even that is tile data.

>> No.10491781

>>10491741
>C64 disk drive is objectively shit. It's an obsolete hardware from the commodore pet era because they wanted backwards compatibility. Definitely the weakest link in the C64 setup.

Ha no. Actually the drive was so slow because of a really silly backward compatibility reason.

>the VIA chip in the VIC-20 was buggy and couldn't do higher speed transfers reliably
>the 1541's firmware was programmed to use a very slow transfer rate so it would be compatible with VIC-20s
>the C64 had different CIA chips that didn't have this bug but the 1541 would still default to this very slow transfer speed
>what all fastloaders do is simply re-program the drive to operate at a higher transfer speed

>> No.10491857

>>10491476
>do they really all have to do that blurbblurbblurb sound?
That's just what the typical 80s pop music sounded like. I like it.

>> No.10491875

>>10491019
You mean there would be no ninten yearolds and sega downies? Is that supposed to be a bad thing?

>> No.10491881

>>10491758
>The Spectrum needs pre-calculated values stored in lookup tables to do the same thing, but at least the bitmap is fast enough to render transformed graphics.
The Z80 is also powerful enough to move the graphics around at an acceptable clip. Attempting 3D or vector graphics on 6502 sucks (the Atari 8-bit was ok at it though as its CPU was pretty fast)

>> No.10491920

>>10491440
>>10491405
The longest 8086 instructions are 5 bytes for indexed indirect addressing or inter-segment jumps (eg. JMP 6000:A930). On 386 and up where 32-bit values are used they can be up to nine bytes (eg. MOV EAX,[EBX+10000000],C00010FF) and up to 18 bytes on x64 (eg. MOV RAX,[RBX+1000000000000000],C0000000000010FF). It's not a huge difference but it can result in bigger code than the 8-bit CPUs where nothing is longer than three bytes.

>> No.10491926
File: 282 KB, 628x628, 1695830596346068.png [View same] [iqdb] [saucenao] [google]
10491926

I love how you old folks ran out of actually worthwhile C64 games to talk about almost immediately and went to talking about hardware and coding. There are maybe 4 worthwhile C64 games and the only thing interesting about the system and it's games are the interesting ways that people used and overcame it.

>> No.10491928

>>10491781
Yeah that was a shame, the drive really flies with fastloaders. Even the VIC can get a good rate with JiffyDOS.

>> No.10491932

>>10487713
I'm 50 years old now and CPM was almost completely dead by the late seventies. About all it was was a laboratory curiosity with a few business applications bundled in

>> No.10491935

>>10491920
also if you didn't know your x86 asm basically on 8086 you could use BX, SI, DI, SP, and BP as indirect pointers. They default to, respectively, the ES, DS, and SS registers but can be altered with a segment override tag. you could not use AX, CX, or DX for indirect addressing but this limitation was removed on the 386 and you got two additional segment registers to play with (FS and GS) although it's irrelevant under modern OSes where you use only one segment anyway so it's basically flat memory..

>> No.10491946

>>10491935
And on 6502 it was like LDA ($50),X where the zero page is used for indirect addressing. In that case A will be loaded with the data contained in the offset at $50-$51 plus the value in X (so if they contain $0010 and X contains 5 then A is loaded with whatever is in $1005 and remember that addresses are little endian first).

>> No.10491953

>>10491539
It's really not, the music is abrasive and it's missing a ton of content.

>> No.10491958

>>10491881
>The Z80 is also powerful enough to move the graphics around at an acceptable clip. Attempting 3D or vector graphics on 6502 sucks
The only difference between 6502 and Z80 is the Z80 processes the data twice as slow per clock due to the 4-bit ALU while the 6502 was full 8-bit. All of these CPUs are powerful enough. The C64 port was the slowest to my knowledge because the CPU was clocked the slowest, but it really wasn't that much slower than the ZX Spectrum port. The ZX Spectrum and the NES ports are about equal in speed, although the NES port is more polished and has no flickers, it was released like 6 years after the original. The BBC Micro original was signnificantly faster than the other three as it's running on a 2 MHz 6502. Of all these ports only the C64 one had Trumbles though, the others didn't have the hardware to support that.

The homebrew Vectrex port is the fastest one right now by far. It has a 16-bit CPU with hardware multiplications and vector graphics, so it's no wonder. It should've been ported to the vectrex in the 80s.

>> No.10491963

>>10491405
>while all 6502 and Z80 instructions are 1-3 bytes

It does take less code to do something on Z80 mostly because 16-bit operations on 6502 require a lot of convoluted zero page gymnastics.

>> No.10491965

>>10491881
>the Atari 8-bit was ok at it though as its CPU was pretty fast
It had no Atari 8-bit port, but it would've been the fastest if ported properly. The CPU was the same speed as the NES CPU but the ANTIC graphics chip was extremely efficient at moving bits around.

>> No.10491967

>>10491932
I'm not sure about that, CPM portables were still a thing in the 80s. The CPM addon for the AppleII was one of Microsoft's best selling products at the time, and CPM was definitely a selling point for 80s systems like AmstradCPC/PCW and c128.

>> No.10491985
File: 137 KB, 688x701, 86555687.png [View same] [iqdb] [saucenao] [google]
10491985

>>10491963
As proof.

>> No.10492001

>>10491926
The C64 is an equally fun system to play games on and to work and experiment with. It's an interesting machine.
It's got a shit ton of obscure games. I know a bunch of really underrated ones.

First Strike (better than any 8-bit Afterburner port)
https://www.youtube.com/watch?v=Ia2P3qJrLmQ

Bop and Rumble (HUGE well animated sprites and pretty unique gameplay and art style for a beat em up)
https://www.youtube.com/watch?v=snqNsoDiCIs

Keys to Maramon (really fun action RPG where you can explore an entire town densely packed with content)
https://www.youtube.com/watch?v=R8kr3VyW4Yg
(i can only find videos of the DOS port)

Citadel (really fun top down shooter slash dungeon crawler, great graphics)
https://www.youtube.com/watch?v=B62BoZzjwR0

Sword of Fargoal (single loader braindead roguelike has never been so much fun)
https://www.youtube.com/watch?v=TWYrOQB6l_g

Space Rogue (Elite but with better graphics, more RPG elements, and single digit framerate)
https://www.youtube.com/watch?v=fdAzM7LY5i8

>There are maybe 4 worthwhile C64 games
There are at least 300 well known C64 games that most C64 owners and players remember.

>> No.10492075

>>10491985
6502 has shit code density, everyone knows that. The 8080, Z80, etc were more carefully designed to minimize memory usage but the 6502's main design goal was being cheap. As I believe was already mentioned, that was an important reason for the Famicom to have a separate chip to put game graphics in, because it used a 6502 and more of the game ROM would be occupied by code than was the case on the MSX or SG-1000. Unlike what anon claimed, it wasn't really Nintendo passing the cost off on the game publisher, there was a legitimate technical reason for doing the CHR ROM setup and that was the choice of CPU.

>> No.10492084

>>10491935
>>10491920
The 8086 has no worse and probably better code density than the 8-bit microprocessors especially if you limit your code to one segment but the 68000 was definitely worse for a couple reasons one of them being the need to always specify a 32-bit value in an unconditional JMP.

>> No.10492085

>>10491926
That's right kid, there's more to life than marios.

>> No.10492113

>>10491965
Not exactly as just like C64 the ANTIC slows the CPU by 20% during active render. The Apple II avoided this issue because Steve Wozniak cleverly interleaved the CPU and video circuit access to prevent a conflict between them. As a consequence the Apple II was quite speedy despite a paper clock speed of 1.2Mhz.

>> No.10492138

>>10491749
The VICII can double scale sprites x and y.

>> No.10492142

>>10491953
Nice opinion, but consensus says otherwise.

https://www.lemon64.com/game/bubble-bobble

>> No.10492163

>>10492075
6502 is also easier to manage tight IO due to the nature of small operations with low clock counts, making cycle counting more manageable and predictable interrupt servicing.

Of course z80 is an excellent CPU and very advanced on comparison, and tight timing is more than possible. But it's just less of a chore on 6502. I remember as well the Stella 20 year anniversary all the old Atari crew basically said the 6502 made the vcs possible

>> No.10492219

C64 arcade ports I like:
Arkanoid
Volfied
Bubble bobble
Gaplus
Ms pacman
Donkey Kong
Commando
Terra Crests
Buggy boy
Toki
Solomon's key

>> No.10492267

>>10492075
Didn't all of those consoles have separate RAM for graphics? Coleco/SG1000 had 16K graphics DRAM and 2K program SRAM.

>> No.10492313

>>10492267
That's probably the main reason TMS systems use z80, because the video ram isn't memory mapped. The CPU needs to shovel data at the TMS VDP and the z80 is well suited to it.

>> No.10492430 [DELETED] 
File: 2.38 MB, 640x360, Ultimate Wizard (C64) 2.webm [View same] [iqdb] [saucenao] [google]
10492430

Ultimate Wizard > Jumpman Junior

>> No.10492453
File: 2.38 MB, 640x360, Ultimate Wizard (C64) 2.webm [View same] [iqdb] [saucenao] [google]
10492453

Ultimate Wizard > Jumpman

>> No.10492672

>>10491741
boy, the c64 disk drive was like a rocket ship compared to the tape deck.

>> No.10492787

>>10492672
Yeah the datasette was exceptionally slow (but also extra reliable) compared to other computers' tape devices, since the standard storage method stored and read all data twice. A lot of games used fast-loaders, but they still needed to read the fast-loader program into memory using the standard slow method first before loading the rest of the game.

>> No.10492908

>>10492267
>Didn't all of those consoles have separate RAM for graphics? Coleco/SG1000 had 16K graphics DRAM and 2K program SRAM.

This is true however the graphics data will be stored in the ROM with the rest of the game data and copied into the video RAM. Usually you have to compress it as well to conserve space which is annoying and extra work. The NES CHR ROM was uncompressed graphics instantly available to the PPU at power on and could be bank switched instantly, and of course you could also have CHR RAM carts if you wanted to do it the conventional way.

So it also was on the 16-bit consoles but they didn't use compressed tiles, couldn't because you're feeding them continuously into video RAM on the fly.

>> No.10492914

>>10492163
The 6502 was the only viable choice at that time as it was cheap (and really they used the even cheaper 6507) and had a high IPS. Other microprocessors available in the late 70s were too slow, inefficient, expensive, used too much power, got hot when running (not that that stopped Mattel from using the GI 1610), etc.

>> No.10492918

>>10492787
The Datasette used digital recording which was more reliable and it had a software-driven interface so could be easily boosted with tape fastloaders. The Spectrum just used ordinary analog audio cassettes which were unreliable but also easy to boost with a fastloader. Unfortunately not possible on the Amstrad as its tape deck had a fixed baud rate.

>> No.10492979
File: 20 KB, 640x400, Deathlord (Electronic Arts, C64 1988).png [View same] [iqdb] [saucenao] [google]
10492979

Deathlord. This game is really cool, it's Satan's RPG.

>go around seven huge continents
>you die once? it writes it to your save file so you have to start over from the beginning.

NES RPGs are child's play compared to this. It was also near a C64 exclusive as the only other system it was on was the Apple II (I'm stunned that they didn't have a DOS PC port for a game released as late as 1988).

>> No.10492991

>>10491985
Neat, I have never seen this chart.

>> No.10492994

>>10492219
Solomon's Key, Bubble Bobble, Toki, and Ms. Pac-Man are definitely better on NES. C64 Donkey Kong has four stages unlike the crap NES port but it's also sluggish and not very optimized. Commando and Arkanoid are better on C64 (especially with the Commando remaster that added the stages left out of the original),

>> No.10493008

>>10492979
RAM is what determines the depth of stats on an RPG. There weren't any consoles until gen5 that had the capacity to fit tabletop RPG stats in them. But a lot of games in gen4 consoles were close enough to do what home computers were doing a decade before them.

>> No.10493057

The Law of the West had a Famicom port but it sucks dick.

>> No.10493212

>>10492914
>>10492163
The Z80 became practical when the improved Z80A arrived in 1980 which had a higher clock speed, was cheaper, and generated less heat when running due to a die shrink. There was no real reason to want a 6502 after that point.

>> No.10493243

The NES was apparently the only system in the known universe to not get a port of Summer Games as you could play it on:

>Apple II
>Atari 8-bit
>C64
>Atari 2600
>Atari 7800
>ZX Spectrum
>Atari ST
>Amstrad CPC
>Master System

>> No.10493269

>>10493243
it wasn't on PC compatibles or Amiga either, so...

>> No.10493356

So why then did Street Fighter 1 and 2 get a ZX Spectrum port but the NES didn't? Check. Mate.

>> No.10493361

>>10493356
why would Capcom bother with SF2 at that late date when the SNES was far more capable of doing an accurate port?

>> No.10493370
File: 4 KB, 256x240, Street_Fighte_II_YOKO_p1.png [View same] [iqdb] [saucenao] [google]
10493370

>>10493356
NES got a fuckton of different Street Fighter II ports in Taiwan.

>> No.10493371
File: 6 KB, 256x240, Street_Fighter_Zero_2.png [View same] [iqdb] [saucenao] [google]
10493371

>>10493356
>>10493370
They even had Street Fighter Alpha for NES there.

>> No.10493375

>>10490234
ok i looked it up. MMC1 may have fixed first bank at $8000-$BFFF or fixed last bank at $C000-$FFFF or you can have no fixed banks (this lets you have multiple game engines). MMC3 fixes $C000-$FFFF to the last bank (yes it's always fixed so you can have just one game engine). the bad part about not using fixed banks in MMC1 is that you don't know what bank will be occupying $C000-$FFFF at power on, it could be anything so you have to waste space with redundant CPU vectors and boot code in each 16k bank. confusing, huh?

>> No.10493382

>>10493375
didn't MMC1 also let you do single screen mirroring but MMC3 did not?

>> No.10493383

>>10493371
>They even had Street Fighter Alpha for NES there.

Yeah, and Mortal Kombat 4 was on the Gameboy Color, big fucking deal.

>> No.10493389

>>10493382
Correct. You can't do single screen mirroring on MMC3 which was annoying.

>> No.10493390

>>10492787
>but also extra reliable

You sound like someone who never had to go through the hell of adjusting the tape headers. For extra fun, stuff you recorded with the header in one position did not load if you adjusted it to another position.

But, do you know what was the one part of the C64 that we can all agree to be complete shit with zero upsides whatsoever? The power supply.

>> No.10493393

>>10493390
>But, do you know what was the one part of the C64 that we can all agree to be complete shit with zero upsides whatsoever? The power supply.
Also I mean the chipset especially the VIC-II got hot enough to roast weenies on. The thermal environment in breadbin C64s was awful.

>> No.10493427

the amount of quality homebrew developed every year for the 8-bit microcomputers still blows my mind

>> No.10493448

>>10492994
I have to disagree on Toki, it looks terrible on nigtendo.

>> No.10493457

>>10493427
Quite a few in the c64 top 100 gaemz.

https://www.lemon64.com/games/votes_list.php

>>10492994
Nintendies fuck off.

>> No.10493460

Double Dragon, though, that was sad and inexcusable.

>> No.10493525

>>10493370
the Master System got a Brazilian SF2 bootleg, clocking in at an entire megabyte of ROM and it came out in 1997, lol

>> No.10493547

>>10493212
6502 has its place as a very cheap and simple CPU core, I remember the Amiga had one for its keyboard controller. Still the Z80 is a work of art with a totally different design goal. MOS/Commodore screwed up by not developing the 6502, it could have been expanded out like the M6809 which is also a great design but was a ripoff even in the 80s. As it is Commodore got stuck using their competitors CPU the 68K like bitches.

>> No.10493572

>>10493547
The Z80 was meant as a better 8080 that used the improved depletion load NMOS process so it didn't need three voltages. It was still relatively expensive, only ran at 2Mhz, and the early ones were 4 μm so they got a bit toasty when running--the TRS-80 Model I used them and was a very cheap, flimsy machine with Eastern Bloc manufacturing quality to reduce costs. The Z80A was shrunk down to 3.5 μm, ran at 3Mhz, and they had 4Mhz ones before long.

>> No.10493590

>>10493547
The 6809 was just a testbed for the 68000, Motorola used it as a proof-of-concept for several things including newer chip fabrication methods and also the hardware multiply/divide feature. It was used in the TRS-80 CoCo because they were offered cheap as a package deal with the supporting chips in the computer.

>> No.10493598

>>10493547
it was meant to sell for $25 a piece for the hobbyist market while the 8080 and 6800 were expensive and targeting entrepreneurial sales. further, the 6502 was depletion NMOS so it didn't need three voltages like the other two chips did.

>> No.10493616

>>10493598
the very early 6502s from 75-76 were 6 μm and they also had a bug where the ROR instruction didn't work. this was fixed by early 77 when MOS shrunk them to 5 μm.

>> No.10493619

>>10492908
you wouldn't fit SMB if you also had to put the graphics data in there as well, the PRG ROM is tightly packed as it is

>> No.10493640

>>10493619
It is but actually the ROM contains a bunch of useless junk from earlier builds of the game. There are some routines that are never actually executed and some that execute but do nothing. I also recall that Sonic 1's ROM has a bunch of old junk from beta builds left in it.

>> No.10493685

NES 1942 sounds like you're pounding on a touch tone phone.

>> No.10493882

>>10493598
Yes very easy and cheap to build an integrated 6502 system at the time, especially as static RAM was prevalent.

>> No.10493890

>>10493640
A far cry from the extreme optimization that VCS devs had to do to fit in their quota.

>> No.10493892

>>10493882
>>10493572
that was also an advantage of Z80, it had on-chip DRAM refresh which saved on components

>> No.10493916

Anyone played these amazing c64 games:

>portal
>sentinel
>spacetaxi
>below the root
>frantic freddie
>fred

Also great arcade ports.
>puzznic
>green beret
>mr do

>> No.10493936

>>10493892
Yeah great CPU and telling it enabled the really cheap systems like ZX80 and then Speccy when DRAM started to scale. It's well suited to the Speccy where programming games requires a lot of memory shovelling, where the 6502 is a nice fit for the c64 and Atari which are more about tickling registers at specific times.

>> No.10494121

>>10491219
Arcade ROMs are a bit deceptive as they can include extraneous junk like a self-test/diagnostic screen and the grunting noise in Donkey Kong is a huge-ass sample that uses 50% of the ROM. So the core game data may not be quite that large.

>> No.10494131

>>10494121
I checked the ROMs for Ms. Pac-Man and Jr. Pac-Man, they're 34k and 56k, respectively. So ok both NES Ms Pac-Mans are 32k NROM carts, fine. We never got a port of Jr. Pac-Man (but would be a great homebrew project) but that would probably be CNROM.

>> No.10494141

>>10494131
>We never got a port of Jr. Pac-Man (but would be a great homebrew project) but that would probably be CNROM

There is technically the Adventures of Lolo 1/2 setup with 64k MMC1/MMC3.

>> No.10494158

>>10493685
yeah yeah Micronics. we know.

>> No.10494181

>>10492084
It's possible Digger wasn't coded in the most optimized way possible but really it's probably because of using bitmap graphics. One of the dumbest things IBM did was to not provide a way to use redefinable characters.

>> No.10494184

>>10488780
An entire country full of public schools with Apple IIs as a market, who would refuse?

>> No.10494187

they put all Sierra AGI games on the Apple II aside from Manhunter: San Francisco

>> No.10494274

>>10488810
The bugs you're referring to are just the result of NMOS AND by default logic. CMOS chips are a lot cleaner and not as glitchy.

>> No.10494413

>>10488486
This is because the VICII and CPU have interleaved clocks so each component can do as it likes without stomping on the other.

This means the display can be safely edited on the fly unlike the new ppu, per >>10488763

>> No.10494547

>>10488036
>>10490654
Someone redid that game recently.

https://www.indieretronews.com/2023/12/tetris-recoded-this-latest-version-of.html

I vaguely recall the original c64 version was written in BASIC and compiled.

>> No.10494551

>>10488901
Why would you play the MSX version of PACMAN when you can play OH SHIT!

>> No.10494558

C64 version of Bionic Commando is s-tier, my favourite version.

>> No.10494586

>>10494413
However the VIC-II controls the system bus so it gets priority over screen access which is why the CPU is slowed down during active render. For certain CPU-intensive tasks like unpacking graphics or fastloaders you will want to disable the video output so the CPU runs at full speed.

>> No.10494634

>>10493301
This didn't get a C64 port back in the day. Jordan Mechner claimed it was because he couldn't find anyone willing to port it.

>> No.10494753

>>10494634
Pretty overrated game. I had it on Amiga it was dull as fuck.

>> No.10494773

>>10494753
it's a glorified tech demo, we know

>> No.10494887

>>10494808
Boogerman is 24 megabits but I understand that's mostly due to all the sprite frames.

>> No.10494996

A few early Famicom games like Bird Week had 16k+16k CNROM but that was stupid because you still can't make any longer of a game than you can with a 16k NROM cart, it will just have some additional graphics, and for the cost of the components (three chips) it just made more sense to use 32k NROM (longer game but with less graphics) or the normal 32k+32k CNROM.

>> No.10495020

>>10494996
I think the second Ninja-kun game was the very first Famicom game to use bank switching and it came out in late '85. Guess it was a proof of concept thing to get a feel of how to develop a game beyond NROM.

>> No.10495054

this the end?

>> No.10495094

I think so.

>> No.10495217 [DELETED] 
File: 347 KB, 415x311, file.png [View same] [iqdb] [saucenao] [google]
10495217

>>10486810
> thread about c64
>>10486821
>>10486829
>>10486836
>>10487028
>>10487148
>>10487751
>>10487856
>>10494996
> NES toddlers hijack the thread
lmao. the seething and eternal jealousy of being given a useless toy for christmas instead of a real computer like a c64 is still a thing in 2023.

>> No.10495340 [DELETED] 

Niggertendo fuck off, this is a quality thread.

>> No.10495347

I've got a supercpu, pretty nifty device but the best peripheral of all is the reu, shame that didn't get critical mass it really lets the c64 shift some bits.

>> No.10495823

>>10487115
it had new zealand story and ghosts'n'goblins which is all you will ever need

>> No.10495834

>>10492979
>>you die once? it writes it to your save file
So just like Fire Emblem then

>> No.10495840
File: 48 KB, 640x640, 1685996181884479.jpg [View same] [iqdb] [saucenao] [google]
10495840

>>10490323
This except unironically. Remember when they were having Nintendo Power threads about 2008 issues and mods were allowing them? Their excuses were shit like "Actually they mention an NES game in the bottom right corner of one of the 100 pages so it's completely retro"

>> No.10495874
File: 2.53 MB, 4000x2200, Sega-Master-System-Set.jpg [View same] [iqdb] [saucenao] [google]
10495874

>>10486810
Sega master system was technically the best 8 bit machine. It would have been much more successful if the nintendojew hadnt blocked its access to third party developers.

>> No.10495982

>>10495874
Good system, but nogaems and no keyboard.

>> No.10496029 [DELETED] 

>>10495217
meds

>> No.10496131

>>10494887
ROM size has very little to do with how many levels the game has. Bugs Bunny Crazy Castle for example was like 60 levels in just 96k of ROM but they're basically three different graphics and sprite sets that repeat over and over.

>> No.10496160

>>10496131
Furthermore SMB3 has 90 levels, it's one of the longest games in the NES library and is 384k while Kirby's Adventure has twice the ROM but just 42 levels.

>> No.10496373

>>10495874
>terrible soundchip
>same sprite and tile limitations as the nes, plus no sprite mirroring
>no RAM
>no games
>b-but muh gwafix!
It's shit.

>> No.10496847

>>10496373
>no RAM
It has 8k RAM while the NES has just 2k.

>> No.10496998

>>10496160
>>10496131
right. it's more the amount of unique graphics, sprite frames, power ups, enemies, etc that determines the size of a game.

>> No.10497179

https://www.youtube.com/watch?v=phVP8_PD0c4

this looks like Atari 2600 shit

>> No.10497195

>>10497179
That's a really early one and it's a port of a VIC-20 game.

http://www.zimmers.net/anonftp/pub/cbm/vic20/roms/8k/index.html

>> No.10497216

>>10497195
The game seems awfully simple even for 8k. Looks more like 4k.

>> No.10497780

>>10497216
as anon said, the smallest NES games are really 24k (16k+8k)

>> No.10497839

>>10497179
the 2600 is somewhat unique in lacking actual graphics data as the code loop draws everything on the fly. disassemble a 2600 ROM and you will not find any graphics data in there.

>> No.10497886 [DELETED] 

>>10497839
Right. A typical 4k 2600 game is more like 8k on other systems as there's no graphics data in there taking up space. So it sounds small but it's really a little more space than you think as the ROM will be mostly all game logic. However the 2600 can also only "see" 4k of ROM at once so larger bank switched games are just several 4k programs linked together and often repeat core code between banks. For example Montezuma's Revenge is 8k and duplicates the game engine in both halves but each half contains a separate group of rooms. You're still effectively working in that 4k box but you can have multiple boxes.

>> No.10498147

>>10493916
>puzznic
>green beret
>mr do

Definitely the best home versions.

>> No.10498198
File: 1.93 MB, 3008x3861, IMG_1018.jpg [View same] [iqdb] [saucenao] [google]
10498198

>you will never retire early and be able to move to a cabin with a c64 and a stack of books and no internet

>> No.10498278
File: 34 KB, 602x338, desktop-667.jpg [View same] [iqdb] [saucenao] [google]
10498278

BTW anons you guys are wrong and retarded most 16-bit games absolutely do use compressed tiles and lots of them. disassemble any SNES ROM and you won't find readable stuff in there. also the main difference between a CHR RAM and ROM NES game is that the former has compressed graphics in the PRG ROM. yes they could have done Metal Slader Glory in 512k PRG+CHR RAM but with a lot of compression instead of using a fuckhuge 512k CHR ROM so the game ended up 1MB. it was easier that way, though (albeit expensive).

>> No.10498298

>>10498278
>it was easier that way, though (albeit expensive).
so much easier that HAL almost went bankrupt from that game and have totally disowned it and pretend it never happened

>> No.10498320

http://www.devrs.com/gb/files/gbmbcsiz.txt

it seems like Gameboy games quite often had 64k ROMs while NES games that used that (meaning a 64k PRG) were rare and a bunch of those were unlicensed Color Dreams games (they seemed to always use 64k PRG+64k CHR which never appeared in any licensed games).

>> No.10498608

>>10497179
>1982

That was games in 1982 when the new wave of cheap big RAM computers was released. In 1983/1984 we see a big paradigm shift as systems like c64/speccy get critical mass.

>> No.10498609

>>10498278
Nobody cares, fuck off tendie this is a patrician thread.

>> No.10498629

>>10498278
I agree, the CHR ROM setup did make the programmer's life easier as everything was uncompressed and instantly available and ready to use at any time.

>> No.10498751

>>10498278
16-bit systems could do that because they had plenty of RAM. The NES is not only starved of RAM, it also needs the CPU to read the data as is. It's a huge design flaw because Nintendo refused to spend more on RAM.

>>10498629
But the consumers would need to pay more for the ROM and SRAM in the cart. Also it didn't necessarily make it easier for the programmers, it depended on whether the publisher was willing to produce more on ROM and add ons. If they're not, the devs would be forced to cut back their games. Which isn't the case with C64 devs.

>> No.10499118
File: 3.71 MB, 498x493, 1700745272252735.gif [View same] [iqdb] [saucenao] [google]
10499118

>>10486810
Where are my Emlyn Hughes International Soccer homies at?

C64 had a ton of good divegrass vydia.

>> No.10499171

>>10499118
International soccer was s-tier pack in game.

>> No.10499193
File: 94 KB, 910x761, FlLJnF6XoAATe-i.jpg [View same] [iqdb] [saucenao] [google]
10499193

>>10499171
Indeed, for its time it was a genuine technical marvel, people really underestimate how hard it's to replicate a complicated sport like this into a video game where 90% of the players are AI controller for pretty much the whole match.

>> No.10499197

>>10495874
The sound chip sucks and I'm not even anti-Sega (I prefer the Genesis to the SNES)

>> No.10499442

>>10496373
>>10499197
>soundchip le BAD!!!!
It's barely any fucking different from the NES chip, which I know you're gonna be sucking off. They're both bleep bloop bullshit. How can anyone really try to make this claim in good faith?

>> No.10499485

>>10499442
>bleep bloop bullshit
Thank you for saving everyone some time by letting us know your opinion is worthless

>> No.10499502

>>10499485
No retort. The NES and SMS soundchips are virtually identical. C64 mogs both.

>> No.10499516

>>10493916
>>frantic freddie
No, but I really liked Fiendish Freddy. The music is still stuck in my head.

>> No.10499528

>>10499502
nah the Master System has the same ancient bleepy TMS9919 chip from the 70s that can only do three square waves+white noise, except they lowered the pitch slightly to make it sound less annoying. it's much less than either the C64 or NES APUs.

>> No.10499539

>>10498751
>But the consumers would need to pay more for the ROM and SRAM in the cart.

Doesn't matter. Publisher has to pay for it up right to make the carts, so if they don't sell everything they will net giant losses. If they estimate the amount of sales too high, they will net giant losses. If they estimate the sales too low, they will never make as much money as they could have. Plus it takes 2+ months to ship an order of carts.

There's a reason why CDs became so widespread despite being a shittier medium in every way except size.

>> No.10499545

>>10491405
CGA graphics use 4 bits per pixel so if you organize them as 8x8 tiles they're 16 bytes a tile same as the NES. Tiles on C64 only take eight bytes to store (however sprites take 64 bytes)

>> No.10499597

>>10499528
>it's much less than the C64
Sure.
>or NES APU
Wrong. "Three square waves + white noise" equally describes the NES. The C64 sounds like a real synthesizer, the NES and SMS both sound like ice cream truck jingles. Any difference between the two is pure pedantry.

>> No.10499670

Master System games also use 32 byte tiles so the graphics take twice the space of NES graphics. This meant you either paid for a larger ROM or abused the tile flip feature to cut down on the amount of tiles you needed.

https://segaretro.org/List_of_Master_System_ROM_dumps

>> No.10499692

>>10499528
Compare The New Zealand Story, Double Dragon, or Bubble Bobble on both SMS and NES to see how crappy the former's sound is.

>> No.10499728

>>10499692
>Double Dragon
>Bubble Bobble
https://www.youtube.com/watch?v=DoJ7YFUotTA
https://www.youtube.com/watch?v=h4rqQU4pvH0
It's ice cream jingle shit. There's nothing here that sounds any better than what the SMS is doing.
>New Zealand Story
This one is the same sounds with better production. The SMS can do this too.
https://www.youtube.com/watch?v=K_gjQHAG_ws&list=PLCD3DFE9D55040CFD&index=1

>> No.10499785

>>10499692
https://www.youtube.com/watch?v=o39KTDiMqdM

Ugh, cover your ears. Not to mention it's only got three channels as opposed to the NES's five so music is always being cut for SFX. Imagine trying to do the Mega Man 1 soundtrack on here and how horrifying that would be.

>> No.10499801

>>10499785
>comparing a Tim Follin NES OST with a TekMagik SMS OST
>pretending the hardware has anything to do with it
Why are tendies always so disingenuous? Two can play at that game:
https://www.youtube.com/watch?v=qhSNmb-4Qr0
https://www.youtube.com/watch?v=qMoFiHZ8qyE
Wow, the NES sounds like fucking garbage!

>> No.10499810

>>10499528
NES has five channels (2x square/pulse, white noise, triangle, and PCM). C64 has three which can be any selection of square/sawtooth, triangle, or white noise but there's no independent volume control like NES has (except the triangle channel is fixed volume) so it's hard to do dynamics. Playing samples on the SID is also basically a hack and the 6581 and 8580 have two completely different and incompatible methods of doing it, in addition it's really CPU-intensive so can only be used on static screens.

>> No.10499823

>>10499810
>there's no independent volume control like NES has
You have no idea what you're talking about. That's just flat-out incorrect. Also, samples on the NES are extremely muffled, take a ton of cartridge space, and interfere with controller polling, so they were often unused. You also totally fail to mention the C64's analogue filter with lowpass/highpass/bandpass and resonance control, ring modulation, sync modulation, or the ability to combine waveforms.

>> No.10499871

>>10499785
the scrolling is chop as fuck too while the NES game runs at 60 fps

>> No.10499886

>>10499871
You sure that's not an emulator issue? Most of the emulator footage of the NES version also doesn't seem as smooth as I remember it to be.

>> No.10499889

>>10499871
>New Zealand Story, The 128k PRG / 128k CHR H MMC3 (4)
Congratulations, when you put a cheating expansion chip into an NES game it helps the NES run games a bit smoother. SMS games don't use expansions by the way.

>> No.10499904

>>10499889
the Master System game is also bank switched and uses the standard Sega memory mapper just like all games larger than 32k and no, MMC3 doesn't do anything to improve scrolling outside that it can soft select the mirroring direction. i mean, SMB is 60 fps and it has no mapper at all.

>> No.10499924

>>10499904
>MMC3 doesn't do anything to improve scrolling outside that it [does something specifically to immensely help with scrolling]
It's really sad how disingenuous you guys need to be in order to pretend like the NES was competitive hardware. This doesn't make you look good.

>> No.10499937

>>10499904
>MMC3 doesn't do anything to improve scrolling outside that it can soft select the mirroring direction
The Master System uses what's essentially single screen mirroring it doesn't have the NES's weird doubled tile map. What sucks about it is that you can't do mid-line scroll changes which was especially bad for racing games. You also can't really do eight way scrolling on the SMS, games pretty much have to scroll only horizontally or vertically.

>> No.10499945 [DELETED] 
File: 10 KB, 325x325, 1694630105980536.jpg [View same] [iqdb] [saucenao] [google]
10499945

Man, Auster is pissed today

>> No.10499954

>>10499670
So yeah. You might have not needed to pay for a CHR ROM on the Master System but the graphics were bigger so you had to pay for a 256k ROM in many cases where the NES could get away with 128k.

>> No.10499974

>>10499937
you can set single screen mirroring with some mappers mainly MMC1 and AxROM. it makes coding scrolling routines a little simpler.

>> No.10499983

>>10499954
>but the graphics were bigger so you had to pay for a 256k ROM in many cases where the NES could get away with 128k
that's the point. a bunch of games like Bart v. the Space Mutants and Double Dragon required a 256k ROM on SMS to fit the larger graphics tiles.

>> No.10500170

https://www.lemon64.com/forum/viewtopic.php?start=30&t=77960

See discussion here. You can pack a large amount of graphics into a small area. That said the de-packing routine and compressed graphics still take some space so the NES's separated CHR ROM did provide some advantages in saving PRG space for other things. Particularly because of the 6502's kind of bad code density.

>> No.10500315

>>10486881
they did, the Commodore MAX machine just didn't take off in Japan
Jack Tramiels attitude towards the Nips may not have helped

>> No.10500415

VSP scrolling also didn't work on some VIC-IIs but reportedly the fix for this was to remove the DRAMs and replace them with SRAM.

>> No.10500897

You can pack a lot into a little with proper compression. Dragon Quest II in the original Famicom release was an UNROM cart and it fit a huge game world into 128k of space.

https://www.woodus.com/den/gallery/graphics/dw2nes/maps_overworld/dw2-over.webp

Imagine fitting all this plus the towns, dungeons, other areas, enemies, sound data, and game logic in 131,072 bytes.

>> No.10500902

>>10500897
the US release was 256k though, was it not?

>> No.10500916

>>10500902
Yes I'm pretty sure that was so they could fit the additional animated intro sequence.

>> No.10500925

Can you at the very least post 10 notorious games on this system?

>> No.10500963

>>10500925
Ten horrible C64 games? Ok.

>Galaxian
>Double Dragon
>Hard Drivin'
>Ikari Warriors (NTSC version)
>Cisco Heat
>Intergalactic Cage Match
>Line of Fire
>Bionic Granny
>Touchdown Football
>Guerilla War

>> No.10500996

>Mega Man 1 - UNROM
>Mega Man 2 - 256k CHR RAM MMC1
>Mega Man 3 - 256k PRG+384k CHR MMC3
>Mega Man 4 - 512k PRG CHR RAM MMC3
>Mega Man 5 - 256k PRG+256k CHR MMC3
>Mega Man 6 - 512k PRG CHR RAM MMC3
what was with the odd switch in mappers on MM5?

>> No.10501032

Why do people keep going on about NES rom sizes?

>> No.10501041

>>10501032
idk but it's more interesting than another thread about AVGN or scanline filters

>> No.10501043
File: 96 KB, 647x599, 647px-Vixen_SheFox_Cover.jpg [View same] [iqdb] [saucenao] [google]
10501043

>>10500925
C64 had a lot of shit games, but it's actually hard to come up with anything really notorious, I assume you mean famously bad games.

Knight Rider and Miami Vice come to mind, that's it.

Vixen was kind of notorious for its sexy lady magazine advertisements, but having played it recently, I find it genuinely a more fun game than its reputation would suggest. Not a very good game, no, but far from the worst on the commie.
Barbarian I & II had similar bimbo ads, but were generally well regarded, at least the first one was.
I can personally vouch for Transformers as a legitimate kusoge, but I never heard people talk much about it.
The Great Giana Sisters, obviously, famously ripped off SMB, but wasn't actually bad as far as Mario clones go.
Mermaid Madness is hilarious, but it's kinda obscure.

>> No.10501057

>>10501043
It seems most of the truly appalling C64 games are either arcade ports or really amateurish stuff made by one guy in his living room, given that anyone could make a home computer game.

>> No.10501335

the cartridge slot on C64 could only support 16k ROM and cartridge games basically vanished after the early days of the system

>> No.10501364

>>10501032
Because we can't have a single damn thread on this board without the tendies overrunning it.

>> No.10501459

>>10501335
That's not totally accurate, the IO block is 16KB but trivial to bank switch. Commodore released a cart-only console version late in the game which had a few decent games, and some modern homebrew is cart based like UltimaIV remastered.

>> No.10501468

>>10501043
Stroker is probably the infamous game and widely spread. There are a ton of shit and bad-taste games out there though because basically anyone could write one.

>> No.10501479

>>10499516
Frantic Freddie is an awesome game, some of the best early soundtrack examples and fun arcade action.

>> No.10501484

>>10501364
Nigtendo is cancer.

>> No.10502481

C64 is the standard platform for demos, everything else is just screwing around in comparison.

https://www.youtube.com/watch?v=3aJzSySfCZM

>> No.10503986

>>10502481
I love the animations, but it still technically doesn't beat the Amstrad Batman demo.

>> No.10504151

>>10503986
Batman gets by because the machine has more colours and higher res as does the amiga, but nobody has produced that good a demo since 2011. C64 has a constant stream of demos, it's the reference demo platform.

>> No.10504250

>>10504151
The Amstrad has lower resolution actually, but it has no color attribute limitations. Unlike the C64 it could put render any pixel of any color in the palette anywhere on the screen. The Amstrad had the best bitmap graphics of all 8-bit machines and the Batman demo couldn't be done on the C64. The only reason the Amstrad didn't get more demos is it's just a less popular machine.

>> No.10504521

the Amstrad had 16 color bitmap graphics but they ate 16k of memory and were very slow so most of its games ran like molasses. lazy Spectrum ports didn't help either. the best Amstrad games were French ones as they didn't have Spectrums there which prevented that problem.

>> No.10504529 [DELETED] 

>>10486839
Yeah, but it had Mode 6, the prequel.

>> No.10504539

>>10504521
>the Amstrad had 16 color bitmap graphics but they ate 16k of memory and
It's not really any worse than C64 because most games set the VIC-II page to the top 16k of memory which leaves you with 48k usable RAM for everything else.

>> No.10504907
File: 926 KB, 3264x2448, dead SIDs.jpg [View same] [iqdb] [saucenao] [google]
10504907

oh dear

>> No.10504934

>>10486829
>mode 7
Idiot zoomer. Pay attention next time you watch your streams.

>> No.10504961

>>10504907
The analog filters on the 6581 are very easy to damage from ESD because the traces are extremely close to each other. That's by and far the biggest cause of the chips shitting themselves.

>> No.10504991

>>10488750
>Sierra had a massive beef with Commodore since they lost a ton of money on cartridge games in the video game crash.
Source? Because Sierra continued to produce games specifically(and even exclusively) for the C64 all the way up to 1986, when it was clear that IBM PC's could do superior graphics and would continue to improve.

>> No.10505343

>>10488732
>>10488750
>>10504991
The only game Sierra developed between 1986 and 1995 is King's Quest. It also came out for the ST and Amiga too. They kept making games for the Amiga until Commodore went out of business. They stopped making C64 games simply because it had too little RAM for the kinds of games they're making.

>> No.10505349

>400 posts and counting
C64 is the best retro system, after all.

>> No.10505351

>>10505343
>They stopped making C64 games simply because it had too little RAM for the kinds of games they're making.

yet somehow they thought putting KQ5 on NES was ok

>> No.10505359

>>10505343
the Amiga ports of their games were pathetically shitty. they just copypasted the EGA graphics and PC speaker sound and ran like crap because they weren't optimized for shit.

>> No.10505376

>>10504250
Regardless batman hasn't been exceeded in many years where the c64 keeps pushing the boundaries, because it's the reference architecture for demo scene.

>> No.10505683

>>10505351
The NES was selling like crazy back in 1990. It's also a severely cut back port. They could've ported it to the Genesis if they wanted it to be a decent port, but they were cashing in on the NES' success.

>> No.10506597

>>10505683
>They could've ported it to the Genesis if they wanted it to be a decent port, but they were cashing in on the NES' success.
They were; it was supposed to be a SCD game but the idea was dropped.

>> No.10507195

>>10505349
If only we could have a patrician 64 discussion without nintoddlers polluting it.

>> No.10507260

>>10506597
The PC KQV was 7MB in size. I suppose a 24 megabit cartridge would work while noting that VGA PC graphics are twice the size of Mega Drive graphics (organized in tile form, each 8x8 block would take 64 bytes). But they wanted to make a SCD game for cost reasons and so they could have the voice samples and CD music from the PC.

>> No.10507281

>>10504907
Fucking lucky bastard.

>> No.10507408

unlike NES or Master System C64 can't flip sprites or tiles in hardware

>> No.10508040

>>10507408
Why would it need to? The graphics data isn't stored in the ROM, it has a huge RAM. With self modifying codes you could scale sprites and scroll tiles with minimal CPU cycles, let alone flip them.

>> No.10508072

>>10508040
>The graphics data isn't stored in the ROM, it has a huge RAM. With self modifying codes you could scale sprites and scroll tiles with minimal CPU cycles, let alone flip them.
Flipping graphics objects upside down in software is trivial, flipping them left or right is more involved and CPU-intensive.

>> No.10508138

>>10508072
>flipping them left or right is more involved and CPU-intensive
With self modifying codes it's not CPU intensive. A bit more complicated maybe, but there are far more elaborate tricks people have pulled off with C64. For the vast majority of games it doesn't need to flip sprites frequently anyway, just load everything you need and flip the sprites before the level starts.

Meanwhile the NES can't do even the most basic things a computer needs to do such as generating pseudorandom numbers, scaling graphics, and modifying software data.

>> No.10508192

>>10488891
128k is rather overwhelmingly the most common ROM size for NES games, probably 60% of the library has a 128k PRG ROM.

>> No.10508312

10487819
ironic shitposting is still shitposting

>> No.10508337

There are a lot more classic Apple II, Atari 8-bit, and C64 games that got a NES port or if they didn't they should have than vice versa. I can't think of too many NES games I'd really wish were ported to C64; like I never felt I was missing anything by not having Nuts & Milk or The Adventures of Rocky & Bullwinkle on there.

>> No.10508450

>>10508337
Princess Tomato in the Salad Kingdom?

>> No.10508803

>>10487128
Just so you know, SG-1000 Lode Runner was 32k not 16k and it copied the original graphics not that cartoony junk.

>> No.10509738

>most of Commodore community online is Euros
>most of the games that were actually interesting and have held up were American ones
...

>> No.10510160

>>10509738
C64 was extremely popular in the US until Nintendo killed everyone's braincells. Most American C64 games were made by studios rather than bedroom coders.

>> No.10510303

>>10510160
no. C64 peak in US was 1983-87 before Nintendo was really a factor yet.

>> No.10510539

>>10486810
was this considered a "COMPUTER computer" back then or was it more of a toy?

>> No.10510672
File: 221 KB, 1148x724, Dragonskulle.jpg [View same] [iqdb] [saucenao] [google]
10510672

>>10500925
>>10501043
>>10501468
With over 10,000 commercially sold video games for the C64, you're going to have an awful lot of trash. That being said, you didn't often find notorious games as infamous as something like E.T., or Superman 64. I actually find when you dig deep enough into its catalogue, you find rough gems or hidden diamonds.

Actually, scratch that, there is ONE infamous game that actually comes to mind. Highlander. Arguably the worst game on the C64, that I know about at least.

>> No.10511509

>>10510539
i don't think anyone ever did serious spreadsheets on it if that's what you're asking

>> No.10511527
File: 5 KB, 768x494, microsoft multiplan.png [View same] [iqdb] [saucenao] [google]
10511527

>>10511509
Of course there were applications on C64, plenty of them.

>> No.10511538

>>10511527
yeah for like family budgets it was sufficient but it's not that great. you need 80 columns.

>> No.10511556

>>10511527
Multiplan was ported to basically everything that had a disk drive and Microsoft had a scripting engine they used to make these ports really fast and easy.

>> No.10511568

>>10511509
it was used everywhere for everything. Its the best selling computer in history.

>> No.10511716

they still make new 65C02s for embedded systems; modern ones are 600 nm which is about the smallest practical size you can make something with 4,000 transistors.

>> No.10511819

https://www.lemon64.com/games/votes_list.php

As proof. Excluding modern homebrews most of the games on here are NTSC ones. There is a huge number of PAL C64 games but I rarely found one I actually wanted to play.

>> No.10511837

I think pound for pound that the best C64 games are more interesting than the best NES games.

>> No.10511915

>>10510539
>>10511538
It was a home computer rather than an office computer. A budget alternative to Apple II with superior graphics and video game capabilities. The IBM PC was considered an office computer.

>> No.10511924

>>10511837
NES console and games are made for wide appeal rather than pushing the boundaries of technology and game mechanics. In other words, they're soulless.

>> No.10511927

>>10511819
Well yes most of the NTSC games weren't made by bedroom coders.

>> No.10511938

>>10511927
A lot of the earlier stuff like Jumpman, Lode Runner, etc was definitely made by like one guy. Euros however literally choked to death on demoscene effects.

>> No.10511957

>>10511927
it's funny to think that Maniac Mansion was developed on UNIX workstations.

>> No.10511980

>>10511819
but on Lemon64 they hate NTSC machines because they don't have enough blank time to do graphics effects

>> No.10511984

>>10511980
i saw a european shit on the homebrew metal gear port for not having a bunch of parallax effects once. they simply have no taste.

>> No.10511990
File: 29 KB, 640x400, Avoid The Noid.png [View same] [iqdb] [saucenao] [google]
10511990

I like this better than the more well-known DOS PC version.

>> No.10512032

https://forums.atariage.com/topic/299298-ti994a-starts-to-distort-sound-and-picture-after-10-minutes/

TI-99/4A not a C64 but...

>sound and graphics start shitting themselves after a while but it works ok when I have a fan blowing on it
They thought it was a VDP issue but if it was just the VDP at fault you would just have screwy graphics but the sound and game logic wouldn't also start glitching out. I wonder if he didn't have a bad trace on the motherboard somewhere that was causing an open circuit as it warmed up.

>> No.10512035

>>10511938
>A lot of the earlier stuff like Jumpman, Lode Runner, etc was definitely made by like one guy.
They were made by computer science students. They had been making video games since the plato mainframe era. Bedroom coders were self learned programmers who tried to mimic their favorite arcade games rather than that.

>> No.10512042

>>10491445
It did, but you only had a size doubler on the x and y axes. You didn't get arbitrarily-sized sprites.

>> No.10512054

>>10512032
funny story about those is that the beige TI-99/4A had a modified OS ROM to prevent the use of unauthorized cartridges especially Atarisoft ones but a lot of customers were infuriated that those didn't work so they would swap them with the older OS ROM (which was easy because TI sold the v1.x ROMs as a separate component you could buy)

>> No.10512064

>>10512032
VDPs were known to get quite hot and needed a sink because they used a big 4 micrometer die. this was eventually shrunk to a smaller size which got rid of the heat issue; the variants used in SG-1000 and MSX are later VDPs that don't need a heat sink anymore.

>> No.10512274

>>10490652
The late 80s chip shortage was SRAM, it didn't affect ROM chips.

>> No.10513357

>>10512032
>They thought it was a VDP issue but if it was just the VDP at fault you would just have screwy graphics but the sound and game logic wouldn't also start glitching out.
The VDP generates the clock signal for the sound chip so if it has an issue the sound could certainly malfunction.

>> No.10514304

>>10512274
Nintendo carts used SRAM too.

>> No.10515458

>>10510160
Most American computer gamers moved on to PC clones (especially once Tandy color+sound became common) rather than consoles. If you look at usenet archives from the era, the overwhelming majority considered the NES to be a kid's toy that didn't have enough memory to play the autistic RPG and sim games that were popular.

>>10510539
Definitely more firmly in toy territory, much to Jack Tramiel's chagrin. Businesses that weren't wedded to CP/M usually opted for Apple II. Schools opted for Apple II (thanks to generous discounts). And hobbyists also opted for Apple II due to expandability.

C64 was for games and maybe light productivity. The lack of consistent 80 column support really hurt it in the professional space.

>> No.10515982

>>10515458
>much to Jack Tramiel's chagrin
But he intended it to mainly be a video game system, much like the VIC-20 was. Why else would it have a sophisticated sprite and scrolling system?

>> No.10516013

>>10511509
Yeah I hardly knew professional software, besides games, existed, until later when we got a Mac.

My dad used it for some practical stuff, but I think mostly then like an automated calculator where he'd write simple BASIC programs to speed up and automate calculations he had to do over and over. For anything to do with writing we had a typewriter though.

>> No.10516424

>>10511924
>NES is soulless
Now I've heard everything.

>> No.10517061

The issues with the Plus/4 were apparently some kind of mixture of faulty manufacturing and die size issues with the TED chips. The C16 was apparently more reliable though.

>> No.10517773

>>10517061
The c16 had identical problems. Still I had one and loved it.

>> No.10517801

>>10517773
>>10517061
The Plus/4 had a worse thermal environment than C16 as the case had nonexistent ventilation and there were more components in there to generate heat. You can heat sink the TED and CPU and also rip out the 3+1 software ROM as it's useless and you'll reduce power consumption and heat generation a little bit.

>> No.10517829

As others have said MOS had trouble with the 3.5 micrometer process used for 7xxx series chips as they had a high defect rate due to an issue with wafer contamination and also ran hot. This was finally fixed when they switched to the 2 micrometer process on 8xxx series chips. The PLA chips had such low yields at first that they purposely shipped machines with known bad ones to meet shipping quotas with the idea that they could be returned for a working one.

The VDU chip in the C128 was averaging about 25% yields in the initial run and they also got nuclear hot when running. The C128 CP/M was developed on a prototype unit where the programmer reportedly had to have the case open and an ice cube in a tray sitting on top of the VDU to keep it from overheating.

>> No.10517830

>>10517801
Did people in the 80s not have heatsink and cooling fans?

>> No.10517849

>>10517830
Commodore didn't, anyway. A lot of this stuff wasn't understood as well back then but then again cars also used to overheat a lot until improved cooling systems starting in the '70s. Modern desktop PCs have fan stacks and holes drilled in the case to keep air circulating.

>> No.10517861

>>10517849
it helped when CMOS chips became near-universal in the '90s.

>> No.10517864

>>10517801
The c16 had a power regulator on the motherboard to step down 9v DC to 5v, the plus4 had a c64 style brick.

>> No.10517905

>>10517829
>as they had a high defect rate due to an issue with wafer contamination and
Probably thanks to MOS's outdated equipment. They were still using contact press lithography which is unreliable and leads to a lot of wafer contamination and low yields.

>> No.10517921

>>10517061
TED is a quite busy chip; it handles all video, audio, I/O, bus control, and RAM refresh and it's quite overworked for the process used.