/vr/ - Retro Games

the whole problem with group projects on 4chan is they usually fail because anons don't have a unified vision for it

>>7016584
What project are we even doing exactly and on what system?

I was pretty sure there already was one of these, because I played it on a Famiclone. Was it a bootleg?

Okay, I just found out Millipede is a different game to Centipede.

>>7016675
Joust, Millipede, and Stargate (ie. Defender II) were ported to the NES by HAL Labs and released in 1988, but Atari's arcade division had earlier planned to release a few ports of their games including Centipede. These were meant for a Japan-exclusive release but the plan went awry when they found that the consumer products division the Tramiels controlled owned all Atari IPs created prior to July 1984.

>>7016694
ok

>>7016584
what a fucking colossal waste of time

>>7016718
>what a fucking colossal waste of time

what's a waste of time now?

>>7016675
You'd probably be surprised at how many 80s arcade games had sequels nobody gives a fuck about.

>>7016730
Pac-Man, Galaxian, and Donkey Kong being noteworthy exceptions of course.

>>7016584
>I'd actually had a couple of ideas for homebrew projects/ports on the NES or possibly other machines. Perhaps /vr/ can do another project together like we did with Zniggy.
Ok, shoot.

hopefully something relatively short that can fit in NROM. lal.

How about hopefully not another ZX Spectrum project? Frankly one was too much.

>>7016584
I'd thought about one a while back. The Colecovision didn't work because I couldn't fit the game into 32k of space, the NES has too many banking options, and Master Systems are a bit hard to find in the US. So I went with the MD instead. No banking, god level CPU, and easy as cake to program for.

Why not code retro style games in Unity instead?

>>7016815
where's the fun in that?

>>7016584
>I'd actually had a couple of idea
There's no shortage of those. People with the skills and attention span required to complete a game are the problem. Zniggy was one guy. People did shitty fucked up levels that he fixed and imported into his game. That's about all you're gonna get out of /vr/.

>>7017109
>People did shitty fucked up levels that

It was a Spectrum game. It fits. (^:

>>7017109
Zniggy has never even been made into a complete game file right? Isn't it a bunch of different shit you have to download and compile yourself?

>>7017109
But that's the thing. Zniggy was one guy who had an obvious idea of what he wanted to do with the game. A homebrew project only works when everyone's on the same page.

>>7017748
Apparently the Centipede thing in the OP is also just files you have to compile yourself.

Centipede would have been super easy to port anyway because the arcade game used a 6502.

>>7016584
Alright, but you need to pick an idea.

>>7016815
>>>/reddit/

>>7016739
When was the last time you played Donkey Kong Jr. for longer than five minutes? Be honest.

>>7016739
Ms. Pac-Man wasn't even created by Namco. Their "official" sequel was the much lamer and less well-remembered Super Pac-Man.

>>7017904
>>>/lgbt/

>>7017818
well, ports are always easier than designing a game from scratch

true

>>7017818
and it's also a very short, small game. the arcade game is just 12k in size.

>>7016792
yeah banking sucks

>>7017109
We don't know what game we're making or even what system to make it on. The OP was really fucking vague.

>>7018425
true

>>7017909
only played the NES version, not the arcade desu

port of Monetzuma's Revenge. it was on the Master System, no NES conversion though.

port of Montezuma's Revenge. it was on the Master System, no NES conversion though. since it was a game that originate on 6502 machines would be fairly easy.

>>7018778
Ok but it's a bigger game than Centipede not to mention a platformer so that's going to be more complicated to program (shmups are pretty easy).

>>7018778
You'd have to disassemble the game and figure out how everything works. There's a bunch of versions of MR, most likely you'd use the C64 or Atari 8-bit ones as your basis since those systems are the most similar to the NES.

>>7018808
not really. neither C64 or Atari 8-bit has anything else in common with the NES but the CPU.

>>7018817
While true, the shared CPU means you can preserve the basic structure of a game and enemy AI routines and whatnot don't have to be rewritten. MR was on three different CPUs.

>6502
>Apple II
>C64
>Atari 8-bit
>Atari 2600

>Z80
>ZX Spectrum, Master System

>8086
>IBM PC

I remember the guy who did the IBM port of M.U.L.E. said that cross ports between the C64 and Atari 8-bit were pretty easy. Mostly you just changed out the sound/graphics and I/O routines and they used the same joystick. The PC was completely alien and nothing worked even remotely like it did on the other machines.

I remember the guy who did the IBM port of M.U.L.E. said that cross ports between the C64 and Atari 8-bit were pretty easy. Mostly you just changed out the sound/graphics and I/O routines and they used the same joystick. The PC was completely alien and nothing worked even remotely like it did on the other machines. He said Atari port to the C64 was translating Italian into Spanish while Atari port to IBM PC was translating Italian into Chinese.

didn't know it had a Zedd Exx Spectrum port

>>7018880
Yeah it was retitled Panama Joe for some reason (bong censorship because they thought "Revenge" was too violent sounding?)

The Master System port I'm very sure was OC donut steal code and didn't use the Spectrum port as a basis, although it would have certainly been possible.

>>7018778
only 16k, would not need a mapper

>>7018898
Or maybe they thought a reference to traveler's diarrhea was gross.

>>7017109
>That's about all you're gonna get out of /vr/.
Ok, what useful contributions have you made short of complaining?

>>7019516
I didn't say I knew how to code or contribute anything useful.

>>7018778
I always liked Shamus but an NES port would be problematic since the game has eight directional shooting and the enemies are made of char sprites which the NES doesn't lend itself very well to.

>>7017748
It has. Pretty sure there was a built image in the git.
>>7017776
Here you go faggot
https://anonymousfiles.io/fBNb6Haa/

>>7017765
A homebrew project, or any project, works best when there's only one page and everyone is forced to work from it. This is why projects with a leader/manager succeed and projects led by committee almost always fail.

>>7018425
OP said NES, which is fairly hard to collaborate on. But no doubt his ideas are vague.

>>7019516
Stating facts isn't complaining kiddo. Complaining about people stating facts is though.

>>7019806
>OP said NES, which is fairly hard to collaborate on
You mean the part where we'd spend days arguing which of the 250 mapper configurations we should use?

>>7019707
The Master System would make it a lot easier. You can do free-form char sprites since you don't have the stupid four colors per 2x2 metatile limit and the D-pad actually has eight directions.

>>7019839
the big issue with Shamus is that there's no Z80 version of the game. it was on the Apple II, C64, VIC-20, Atari 8-bit, IBM PC, TI-99/4A and TRS-80 CoCo. none of these used a Z80 so you'd have to totally rewrite everything from scratch for the Master System which sucks. if you did the game for the NES you could reuse code from the C64 or whatever but the control and color attribute issues would be a problem.

it's not like you can't recode everything for the Z80, it's just a PITA and easier when there's an existing version of the game for that CPU that you can use as a template. funny enough, if we wanted to make a port of Zniggy for the Master System it would be trivial since we could reuse a good chunk of the code and the screen resolution is identical to the Spectrum's.

>>7019814
that's why it's best to start with something modest and not try to make a 256k MMC3 game out of the gate

Jumpman is another computer classic it would be ace to do a port of...but the original game IIRC is big enough to need banking while Jumpman Jr would not (only 16k). Jumpman Jr. also had a Colecovision port so you could use that to develop a Master System port from if you wanted.

>>7019932
>>7019707
>>7018778
right, you see what i mean. that's three completely different games. if you all want to do a homebrew port of something, you need to decide what it is and you can't seem to do that.

>>7019932
>Jumpman is another computer classic it would be ace to do a port of...but the original game IIRC is big enough to need banking while Jumpman Jr would not (only 16k).

wasn't 16k the minimum size for an NES game?

>>7020038
The iNES file format has a minimum size of 16k, but Galaxian used an 8k PRG ROM, the only commercially released game to do so and I believe Space Invaders only had 4k of code although the ROM used was 16k. But it's really a waste of an NES's capabilities to make a 4 or 8k game so for all practical purposes say the minimum size is 16k.

The Master System and Gameboy have 32k as their minimum ROM size, there are no games smaller than that.

>>7019707
They had Shamus on the GBC and...

https://ladecadence.net/trastero/listado%20juegos%20gameboy.html

You seriously mean to tell me they needed an entire fucking megabyte ROM for a game that was originally 16k?

>>7016719
porting centipede to a dead console when you can just play the original on mame or on a dozen different compilations on a dozen different consoles

>>7020091
it's fun. just like the remakes of Atari 2600 Pac-Man and Donkey Kong. they weren't needed per se, but homebrewfags wanted to show that the 2600 could do better than the sorry ports we got back in the day.

>>7020105
then just make an original game for the NES. add something new to the world. it can even be heavily inspired by centipede for christ's steak. all these stupid projects just reinforces my belief that 99% of programmers are completely bereft of creativity.

>>7020106
bit unfair considering 90% of NES games were the same thing anyway

>run around scrolling level shooting/stomping/punching baddies
>beat boss
>get doodad which you use to beat the next boss
>repeat until beating final boss and rescuing your girlfriend/a princess/the president

>>7019814
Of course not. We don't use a mapper because that would require programing techniques that we can't comprehend because our first experience learning to "code" was HTML5, and maybe even knowledge of hardware But we spew a lot of bullshit about how we totally did that on purpose because it's challenging and really harder to do that way and proves what leet haxors we are. Thousands of people actually buy our bullshit.

>>7019863
Porting from 6502 to Z80 would be pretty easy. It's the other way around that's a problem for people who expect to have an instruction for every desire. But why. The SMS isn't a great target system. To produce anything of value you want to be looking at a MD or SFC. These give you enough power and address space that you can write most of your shit in C, meaning more than the 2 people on 4chan who have every written an actual game in 6502/Z80 assembly can actually contribute.

>>7020105
It's very fun. The 2600 is a great console to play with because it's very limited and also very easy to do better with 40+ years of hind sight. But it's limitations make working with the graphics/sound beyond the comprehension of todays pixelshit/chiptunes faggots.

>>7020106
>>7020091
>nobody is allowed to do homebrew projects unless they want to make exactly the same stuff I want to make

>>7020071
Maybe half of it was empty. Who knows?

>>7020050
On that note, the C64 Galaxian is absolute shit. Somebody should remake it.

>>7019814
I assume we'd do something fairly modest here.

>>7019707
if you ignore the GBC remake, this had no console ports which is odd for a popular multiplat computer game of that time

>>7021267
Synapse did license Dough Boy to Kemco who ported it to the Famicom in 85. That was pretty strange since the game is rather obscure and not one of their more well-known titles.

>>7021023
^This.

>hrrpf quit liking what I don't like

>>7020091
>on a dozen different compilations on a dozen different consoles
>a dozen different consoles
Centipede had ports on Atari consoles, Intellivision, and Colecovision. that's only five systems in total.

>>7021425
thank you very much, Wikipedia

The C64 has my favorite port of Centipede, incidentally.

>>7020106
alright, m8. tell us your great original game idea.

>>7019839
The NES Archon managed to get in eight directional moving and shooting but it's clunky.

>>7021480
i forgot about that completely

yeah, press Up/Down and Left/Right at the same time to move or shoot diagonally

>>7019932
Or in reverse like C64 port of Chack'N'Pop (great game btw).

>>7021560
where would Famicom multicarts be without this?

There was an MSX port of Chack'N'Pop that's an almost completely different game.

>>7021467
I never claimed to have any. You did.

>>7021604
>I never claimed to have any
Thought so.

>>7020091
Well apparently a port was planned back in the 80s and never got off the ground. Would you have gone back in time and tell them they shouldn't bother?

If someone has an original game idea, shoot.

>>7021560
Actually I do wonder why this never got a US release.

i dunno, probably because Taito had bigger games to release here with their 5 game a year limit? derp.

>>7021284
not even that good of a game

nah not really

>>7021073
>Who knows?
Any child capable of using a computer. It's roughly 35% empty. And 16/1024!=1/2.

https://www.smspower.org/Games/SnailMaze-SMS

How about we just do Snail Maze for the NES for the fun of doing so? Short little project and it's only 8k in size.

>>7016606
RIP

>>7016739
Even Galaxian had a third game called Gaplus that was so unpopular that they actually had to rename it "Galaga 3" (not even Galaxian 3) because nobody was fucking playing it and they thought putting Galaga in the title would help. Shame, because it's the best of the series.

>>7022928
ok, although it uses split scrolling so you'd still have to deal with sprite 0 crap

>>7022935
Well for starters you picked fucking Yuni as your DDR rep over Afro, Emi, the Robos, the Zukins, or any other character who would make more sense.

>>7022968
Not if you program it cleverly of course. See the score counter? You could make that with sprites, but since there's at least ten characters you'd go over the scanline limit. Instead, shorten "Round" to "R" and "Time" to "T" or maybe a little clock symbol.

The "Goal" symbol could also be made with sprites. When the maze is finished, just turn all sprites off and scroll the next maze onto the screen. Easy and no Sprite 0 stuff required.

>>7022968
Not if you program it cleverly of course. See the score counter? You could make that with sprites, but since there's at least ten characters you'd go over the scanline limit. Instead, shorten "Time" to "T" or maybe a little clock symbol. You should then be able to use sprites for it.

The "Goal" symbol could also be made with sprites. When the maze is finished, just turn all sprites off and scroll the next maze onto the screen. Easy and no Sprite 0 stuff required. Also you'll probably want to set vertical mirroring so the next maze can be easily scrolled from right to left onto the screen

alright then, it's settled. i guess we're porting this silly minigame to the NES.

>>7023006
Bit of a law bar to set, but...meh. it's just a fun exercise anyway.

>>7020050
>and I believe Space Invaders only had 4k of code although the ROM used was 16k

Checked it. The PRG for Space Invaders is 9203 bytes, the rest of the ROM being empty.

>>7023070
did they really need 9k for Space Invaders? most home conversions of the game were 4k.

And actually, it's more difficult to code an Atari 2600 game because of how absurdly timing sensitive everything is. It takes a fuckload of work to get a game working correctly.

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

Here's a homebrew called Munchie Attack. This game is only 4k, but really, what's the point of making a game that small? It's basically an Atari 2600 game that has slightly better graphics. I think 16k is pretty much the minimum size for an NES game that's, well, actually an NES game.

https://www.youtube.com/watch?v=72k1ZYp83tc
https://www.youtube.com/watch?v=P4exGV-XUbQ

For example the NES Lode Runner had additional music and improved graphics because presumably they thought stick figure sprites and clicking noises for sound wasn't acceptable and they needed to do more to create a good impression on the player.

>>7022994
scroll glitches are annoying but it's simply how it is. however being able to use only 256 tiles at once is more of a problem, MMC5 partially worked around it via an expanded nametable that allowed access to 16k tiles at once but that's probably overkill.

>>7024440
256 tiles is not a major limitation if you're clever about reusing them and doing palette swaps.

the NES is the nice middle ground between being powerful enough to make decent games with a lot of content (as opposed to the Atari 2600 which is way too minimal) or 16-bit consoles which are too complicated for one guy to easily do the graphics stuff.

>>7022994
This game is too boring and low content to want to bother with.

https://www.youtube.com/watch?v=8GsAVlKZDDA

How about Ladybug? That'd be a good one to do.

>>7024678
Ok. I took a quick look at the Colecovision ROM. It's a 16k game, but 12k of that is actual code and the remainder is sound/level/graphics data. One of the nicer features of the NES is that the graphics data is offloaded into the separate CHR ROM so that saves space in the main game ROM which you can use for additional music or other content.

bit surprised Ladybug never got on any Atari systems

>>7024720
Coleco got the license for home conversions of it, of course they didn't make games for the 5200 as it was a direct competitor to them. The Atari 2600 port of Lady Bug was cancelled, either because they didn't think the hardware could pull it off (even the Intellivision can barely handle the game) or it disappeared into the mass of vaporware.

>>7024678
We could include a little musical jingle on the between-level screens, that was common in NES games and maybe replace the skulls with a little container of bug spray, which seems to make more sense to me. I thought of having the levels scroll onto the screen but it's probably not doable if you want to keep the score counter design the same.

No stupid five note bass tune during the levels like a lot of early period NES games did though.

>>7024801
>even the Intellivision can barely handle the game

The Intellivision was underrated, in fact the hardware was ahead of its time in a lot of ways.

>16-bit CPU
>up to 50k addressable cartridge ROM (even the Master System couldn't do that much)
>eight sprites per line that could be flipped in hardware
>and sprite to bg priority

On the downside, it only had 240 bytes of WRAM and the screen resolution was really chunky, only 15k total pixels on screen.

>>7024857
have to recode everything as this game doesn't exist in a 6502 version. alas. the arcade game was also Z80-based.

Man it'd sure have been nice if you could use the 6502 decimal mode on the NES.

you have to consider the time period and whatnot for why the 6502 and Z80 dominated

>the Z80 was generally always better capability-wise, but in the early days of the late 70s, it was more expensive than the 6502 and slower
>as prices came down and faster Z80 variants became available, then there wasn't really a good reason to choose the 6502 over it anymore
>Atari had always used 6502s since moving from discreet logic arcade games to microprocessor based ones in 1976
>the best thing about the Z80 was its built-in DRAM refresh which saved a lot of component costs
>Steve Wozniak came up with the idea of using the video circuit to refresh the RAM on the Apple II
>the TRS-80 used a Z80 and required no separate DRAM refresh circuit
>the PET used some DRAM refresh controller but forget what it was exactly, but it was more expensive as a result
>Atari were already used to making custom chips so designing an in-house RAM refresh circuit for the 8-bit computers was fairly trivial

>>7025072
6502 systems:

>Atari arcade games from 1976 to 83
>Atari 8-bit consoles/computers
>Commodore machines
>Apple II
>NES
>BBC Micro

>Z80 systems:

>many early 80s arcade games
>Sinclair machines
>Amstrad CPC
>TRS-80
>innumerable anonymous CP/M business computers
>JPCs
>Colecovision/SG-1000
>Master System
>Gameboy (sort of)

>>7025072
>Steve Wozniak came up with the idea of using the video circuit to refresh the RAM on the Apple II
But hey, look at the Apple II (not II+ or IIe)

The II ROM was very primitive. It was only after many patches, tools, and upgrades were integrated into the II+ that it became a decent machine and every Apple II has that shitty interleaved hi-res graphics memory map. Only the IIgs added new modes that ditch that.

>>7025102
FWIW, that interleaved memory map ended up being a feature on some displays. Really, it's not that bad if you make up an index table. Not optimal, but not horrible either and that is task #1 for an Apple II programmer. It was mine. (I always like to write a dot plotter, then make it fast and the code that drops out of that gets one to a bitter pretty quick).

On scrolling games, slow display fills tend to be seen easily with a wipe or tear effect seen when that operation can't be buffered, or done during one vblank.

The interleaved screen broke that up some. which made it less noticeable. That and binary picture loads looked cool but otherwise PITA.

>>7025110
I vote for PITA. Apple II games ended up being really bloated and needed twice as much code to accomplish the same task as on a C64, plus the greedy 8k graphics page when char mode on C64 only uses 1000 bytes.

If you look at the MSX market, an MSX2 machine included a 6MHz 64180 as a 2nd CPU and then the TurboR was introduced. Maybe MSX would have been popular in the US without IBM.

>>7025163
Likely not. The MSX was overpriced and just had the same old chipset from the TI-99/4A and Colecovision.

>>7025158
yep a giant pile of code and index table lookups to do any graphics operation. too bad because the CPU wasn't slowed down by the video circuit either due to the interleaved memory access.

>>7025179
>>7025158
>>7025110
The typical Apple II game is harder to code than the typical C64, Atari 8-bit, or NES game as the latter have custom chips that take care of the heavy lifting of sound and graphics.

>>7025072
so why do Master System games look almost 16-bit level of good while ZX Spectrum games are...yeah.

>>7025495
ha ha, silly. the Master System has dedicated ASICs to handle sound and graphics while the Spectrum has a frame buffer and a speaker that the CPU has to drive directly, and it has separated video memory that doesn't steal CPU cycles.

>>7025179
>>7025158
On top of that, 6502 code in general takes more memory than Z80 code to perform the same operation.

it's kind of crap that just about no 6502 ever went over 2Mhz while Z80s were making significant speed gains

>>7025515
I think 2Mhz was the ceiling for NMOS 6502s while CMOS versions could attain higher speeds. And maybe the C64 could have been 2Mhz as well?

>>7025519
AFAIK RAM speeds were a limiting factor for a while. By 1983 they had 150 ns RAM and 90 ns two years after that. Perhaps the ROMs would have needed to be re-specced as well.

>>7025529
I'm sure 150 ns RAM predated 1983 by at least a couple years, but was likely expensive before that. The Apple II+ and Atari 400/800 for instance used ancient 200 ns 4116 RAM chips that had been around since 1976.

i'm not sure either the 6502 or Z80 is necessarily better than the other, both have good and bad points. it's like shmups on the C64. i've never understood the cult around Uridium, Katakis, Turrican, etc. maybe because I played shmups on consoles and the Amiga first so the C64 ones felt like an anticlimax.

The Z80 was pretty much the standard for business computers in the early to mid 80s, but all of these machines were pretty generic and boring.

>4Mhz CPU
>80 column green or amber text
>RS-232 port, sometimes a Centronics port
>two floppy drives, maybe a 5MB hard disk if you were rich
>sometimes a built-in video circuit, often a separate serial terminal for video and keyboard input
>64k of memory

If anything, CP/M drove the Z80 and not vice versa. 6502 machines never needed to be designed around a common hardware standard the way Z80 ones were. After the IBM PC arrived, it pretty much made Z80 business machines outdated.

well, when you consider that the ZX Spectrum is the most well-known and well-supported Z80-based computer, it kind of says something.

>yadda yadda 6502=fun and Z80=running WordStar on a monochrome screen and the Zedd Exx Spectrum

Obviously forgetting the Colecovision, MSX, Master System, maybe the Gameboy if that counts, and countless Z80-based arcade games.

>>7025085
I don't really know of much of anyone else other than Atari who used 6502s in arcade machines. Japanese arcade manufacturers nearly all used Z80s from 1980-84.

>>7025625
as I said, the 6502 had a cost and performance advantage in the late 70s but even though the Z80 was the better choice by about 1980, Atari were pretty much locked in their ways and all of their engineering and programming people were 6502 guys. The 6809 was coming into play during this time as well, Williams used it a lot in their arcade games.

>>7025632
>>7025625
The decision to use a 6502 in the Famicom instead of a Z80 was a bit controversial and some Nintendo engineers were against it, they wanted the Z80 so it would be easier to do arcade ports.

>>7025529
>>7025519
The BBC Micro used a 2Mhz 6502 and consequently needed more expensive 120 ns RAM, so they only put 32k in there to keep costs down.

>>7025504
If you have the right video hardware, you can do almost anything. You can have a crapload of stuff moving around when the CPU doesn't have to do anything more than update sprite position counters, switch out sprite frames, and check for a collision. If you need to use a multiplexer, which is common on the C64 and almost a necessity on the Atari 2600, then it runs into more complexity and CPU usage.

>>7025661
https://www.youtube.com/watch?v=pjZ0OHIcJpc

yeah it's pretty fucking easy to do all this when the custom graphics hardware is doing all the heavy lifting. btw this was a 68000 arcade game. now try doing this on an Atari ST or a Mac SE both of which use the same CPU and get back to me.

>>7022928
How about redditots stay on reddit?

>>7022968
DK. It's not just for Donkey Kong.


>>7024985
0/troll. Zoombies don't even know what you're talking about.

>>7025072
>i red da wikipedo
Good for you

>>7025552
Neither are "better". They're both good/bad in their own ways. The zoomies here are just obsessed with turning everything into a binary choice Which is choice considering they insist there are >9k genders.
>>7025579
You sound very confused. You might want to stop watching the youtube for a while. At least until you're old enough to post here.

watch before he starts yelling about Dunning-Krueger again. (^:

I'd still like my original idea of porting Montezuma's Revenge.

>>7025158
that's like IBM games pre-VGA when you needed just ridiculous amounts of code because CGA and EGA had interlaced video memory.

>>7025765

>>7025158
For example Hard Hat Mack was 42k on the Apple II, about twice the size of the C64 version.

Oils Well on the Apple II: 44k
Oils Well on the C64: 15k

Miner 2049er on the C64 and Atari 8-bit: 13k
Miner 2049er on the Apple II and IBM PC: 32k

Montezuma's Revenge on the Apple II and IBM PC: 32k
Montezuma's Revenge on the C64 and Atari 8-bit: 16k

>>7016815
Because no one's gonna go crazy for your shitty ass C-tier game on the Steam storefront.
Real talk, this is kind of an exception since it's an arcade port done out of love, but the majority of homebrew that aren't ports of commercial games are just shitty and I'd wager most people doing them are doing so because "game but it runs on my childhood console" is an insta-notoriety button.

None would survive when pitched against real games on PC, which is a contrast when looking at actual good games from back in the day, since a lot of those games can compete head to head with popular indies from today or even fully fledged commercial titles.

>>7026016
>but the majority of homebrew that aren't ports of commercial games are just shitty

That's why it's easier to do ports rather than take the risk of making an original game. Especially because in this case the NES almost did get an official port of Centipede but got cancelled because Atari's arcade division lost the publishing rights to it.

>>7026016
>but the majority of homebrew that aren't ports of commercial games are just shitty
Unless they're ZX Spectrum games in which case being a commercial release generally has no bearing on the quality of the game, or lack thereof.

>>7025821
>>7025110
That was all because it saved Steve Wozniak one chip.

>>7025163
Should of used a 68000 instead as the standard for all MSX2s while keeping the Z80 for MSX1 support and sound.

That and horizontal scrolling, hi-rez 512x424p (replacing the composite video output) mode, dual YM2608 & YM2164 sound chips (1 of each) and 4 time more sprites (mostly) and backgrounds on screen at once.

>>7025643
It would of brought the cost down, Super Famicom would of used a 68030 just so the CD add on will see a release in that timeline.

>>7026183
>>7025643
They used a 6502 for cost reasons mainly. The 6502 had a smaller chip die than the Z80 and they could integrate the audio hardware onto it, consequently the Famicom only needed two main ICs while they'd need at least three otherwise and Ricoh was already a licensed 6502 second source and had the capability to manufacture them.

Of course a Z80 would have definitely made arcade ports easier to pull off.

>>7026198
wait why did they disable the decimal mode if they were a licensed manufacturer and not a Taiwan-tier bootlegger?

>>7026203
Easy. Ricoh's licensing agreement with Commodore Semiconductor Group was for Japan only. Since they intended to sell the console internationally, they had to cheat by disabling the decimal mode to not violate their license terms.

>>7026203
Ricoh was in a bidding war with Commodore to buy Mos, Commodore won the bid and Nintendo had to cut things out of the chip just to lower the cost and they still had to pay Commodore a $30 royalty check (hence why the SNES didn't have BC with the NES) for every unit sold hence the $150 cost, otherwise it would of had more power, stereo/better sound, RGB video, more ram and removable controllers.

yeah I saw a disassembly of Dragon Quest 1 and they had to jump through hoops for certain game algorithms due to the lack of BCD mode

>>7026224
>Ricoh was in a bidding war with Commodore to buy Mos, Commodore won the bid and Nintendo had to cut things out of the chip just to lower the cost and they still had to pay Commodore a $30 royalty check
Beg pardon? Commodore had owned MOS since 1976 and all that Ricoh actually did was cut a single trace on the 2A01 to disable the decimal mode.

>>7026235
Ricoh was part of that bidding war, they made a agreement after that bidding war.

>>7026179
>Should of
>>7026183
>would of
You missed the could of init luv

>>7025110
the Apple II's HGR mode is bullshit

>the graphics page is organized into 8 byte blocks, each byte within the block representing three pixels
>bytes 1-7 of each row controls the color depending on how each group of 2 bits is positioned
>the 8th bit controls whether each group of three pixels is orange/blue or green/purple
>next byte after that is...guess what? 64 bytes down in video memory thus the first row at the top left of the screen is at $2000 and the row underneath it is at $2080
>and the best part--the bytes for each row are displayed on the screen in the reverse of how they're stored in memory
>and since not all of the 8k video page is needed for the 280x192 HGR graphics, there's a lot of unused "holes" that you can store other things in if you like

tl;dr it's a total spaghetti mess and requires you to be a god of 6502 assembly language to get graphics to work at a reasonable clip

>>7026380
Nah not really. Back in the day the main goal was to get a game finished and shipped on time, not necessarily coding it in the best or most efficient way.

>>7026380
Hence why Apple made the Apple IIe.

>>7026420
dude...it's the same shit until the IIgs.

It's interesting that M.U.L.E. is one of the few major early 80s computer games to not get an Apple II port. The graphics don't seem as if they'd be overly hard to recreate, so I suspect it was more an issue of getting the controls to work properly since the keyboard on the Apple II can't detect if a key is being held down.

>>7026439
really? i'd have thought the Atari 8-bit was worse since you can't detect multiple keypresses with it.

>>7026440
No, it can't detect multiple keys being pressed but there's no issue with doing key repeat. The Apple II can't do it at all. You press a key and it just sends the scan code for that key to a register. The II/II+ had a REPT key that if enabled would cause anything that was pressed to repeat endlessly, but this was removed from the IIe and replaced by a software key repeat.

>>7026424
They fixed the graphics chip for the IIe, IIgs was a completely different system graphics chip wise.

>>7026481
There's no graphics "chip" in an Apple II, it's not a C64 or NES. There's a TTL circuit to generate the video instead.

>>7026165
Component prices in 1977 were expensive.

>>7026520
Uhhh....
https://en.wikipedia.org/wiki/Apple_IIe#Specifications

>>7026542
And nothing's said in there about a graphics ASIC. The IIe had a couple of custom ULAs to integrate some system functions and reduce the chip count from the II/II+ but that's more like how the ZX Spectrum works and there's no dedicated GPU.

>>7026553
GPU were not a thing until the mid 90s, you're thinking of a PPU or a VDP chip.

>>7026380
>not being a god of 6502 assembly language
>being a googlesmart baby
yikes