It is currently Wed Jun 28, 2017 7:12 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 154 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9 ... 11  Next
Author Message
PostPosted: Thu Dec 08, 2016 11:31 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1601
Location: DIGDUG
Quote:
Z80 has AF, BC, DE, HL, AF', BC', DE', HL' that can be used as accumulators. 65xx has A.


Not to nitpick, but in 16bit mode, the 65816 accumulator is referred to as 'C', which has a low byte A and high byte B. See ASM with C in it (TCD, TCS). Also XBA (swap high and low byte).

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Thu Dec 08, 2016 5:06 pm 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 593
Location: Sweden
But since XBA is the only opcode that uses B, it's not useful for much else but as the high byte of the accumulator in 16-bit mode.

tepples wrote:
Pokun wrote:
I'd just send it to a friend with a Macintosh.

What's a "friend", and how does one find one?

You make them (I think).

Quote:
Or can people assume that little supply of free labor to test Mac builds implies little demand for production use of Mac builds?

At least you can assume that people that buy expensive Mac computers are either only interested in using them for websurfing on Starbucks, or are prepared to compile open source programs themselves.

Quote:
Pokun wrote:
For Windows and Linux you need to have to have at least a Linux system and try the Windows build in Wine.

Making a "Windows" program that inadvertently depends on bugs in Wine is like making a "Super NES" program that inadvertently depends on bugs in Snes9x.

Ah come on, someone are going to wine about it if they find a bug. Can't believe this is really that big of a problem.

Quote:
byuu wrote:
I keep waiting for ARM to catch up on performance. We keep inching closer, but it's taking so maddeningly long.

I likewise keep waiting for mass market ARM devices capable of running emulators to catch up on input devices.

Agreed! Smartphones are not good for much else but backgammon or solitair. Can't play action games without the feedback you get from real buttons. It's not as much fun either.


Top
 Profile  
 
PostPosted: Thu Dec 08, 2016 7:39 pm 
Offline
Formerly ~J-@D!~
User avatar

Joined: Sun Mar 12, 2006 12:36 am
Posts: 443
Location: Rive nord de Montréal
Pokun wrote:
tepples wrote:
Pokun wrote:
I'd just send it to a friend with a Macintosh.

What's a "friend", and how does one find one?

You make them (I think).

Last time I checked, make friend failed on my machine, complaining that there's no rule to make target friend. Where do I find a working Makefile for this?


Top
 Profile  
 
PostPosted: Thu Dec 08, 2016 7:48 pm 
Offline

Joined: Wed Nov 30, 2016 9:59 pm
Posts: 52
byuu wrote:
> This is why I don't like ARM platforms being promoted for emulators because it's hard enough to get people with a powerful PC to play a game like it was intended, good luck even getting half the accuracy out of a weak ARM part.

I keep waiting for ARM to catch up on performance. We keep inching closer, but it's taking so maddeningly long.

It's not even about the top-end ARM core being fast enough (which it still isn't quite there yet), we need all the little dev boards (RPi, etc) to be fast enough. Those things aren't even close -- they can barely run minimal Linux desktops.

I suspect we'll be waiting a whole lot longer.

The shift from performance to energy efficiency has certainly hampered efforts to improve emulation accuracy.

> So there is something about cartridge-based systems that don't have internet access, that makes them more of viable hobby/homebrew platform.

To me, even if an emulator isn't 100% perfect, you can get 99.99% perfect. At some point you have to stop worrying about absolute perfection.



It is baffling how frequently these (ARM-based emulators) show up, and use pirated games in the marketing (note screenshots of games that you can not legally buy for the unit alone):
https://www.indiegogo.com/projects/retr ... yer-cool#/
https://retropie.org.uk/

Both of these things use RetroArch which in turn use things like BSNES, SNES9X, ScummVM and MAME which they circumvent the licenses of the emulators by not including the emulators themselves with the hardware, which is why they don't mention the emulators by name in the marketing either, though you can see them in screenshots.

So the question is, why is this 60$ device any better than the RetroN 5 or the RetroFreak which can play your legal carts (with the same emulator cores no less)?

¯\_(ツ)_/¯

The chip used by RetroFreak and RetroN is the Rockchip 3066 which you can buy a devboard for $58 http://www.marsboard.com/marsboard_rk3066_feature.html

The Pi3 is $40 https://www.adafruit.com/product/3055

I can't imagine the experience of the RetroPie/RetroEngine being even usable when the base performance of the Pi3 is so poor relative to a desktop PC, and the emulators are just being compiled, not optimized for the specific multi-core ARM platforms.

Pi3: 478 on Geekbench single thread, that puts its somewhere between the Apple A5 (iPhone 4S) and the iPhone 5 or about the same speed as a Samsung Galaxy Note or S3 Neo. A Intel Atom N455 (think Chromebook) is slightly faster than that. So basically the worst performing Intel CPU in 2010. And yet here we are again with people throwing money at a project that at best gives you a poorer experience than the desktop computer, and at worst, a completely unusable experience.

For reference the ARM part Nintendo used for the mini is a AllWinner R16 (A33) , which has a geekbench score of 309. Something tells me that Nintendo Devs just wanted something cheap so they can port the NES VC emulator to it (likely written in C.) The R16 and the RPi2 use the same ARM Cortex-A7 (ARMv7-A), the RPi3 uses ARM Cortex-A53 (ARMv8-A). For comparison, the 3DS uses an ARM11(ARMv6) like the original Raspberry Pi. Now consider that the SNES emulator on the new 3DS requires the quad-core version of the otherwise identical chip. Did they bury a SNES core in that CPU, or is the emulation not as good as the PPC Wii/WiiU version?

The cheap ARM stuff is barking loudly up the wrong tree. I imagine that only the 8-bit computers even produce 60fps on these devices (and indeed all the videos I see on RPi3's seem to show that 16-bit and 32-bit emulators don't run at 60fps.) They are not going to be 100% accurate, and I don't think they hit 99.0% "good enough" for most games even if the emulators they are using are 99.0% "good enough" on a high-end desktop.

It's not like Nintendo or Sega are ever going to support one of these devices, though at least Sega has released their own emulators for various platforms for Sonic games, thus you can move the ROMS from those into it. I don't ever expect Nintendo to do the same with Mario titles.

I don't have any of these cheap arm-based console emulators, as I would much rather support a FPGA project that can play the original cartridges (or authentic releases on alternate media) then encourage yet more piracy with devices that don't even have a cartridge reader for the device they are emulating.

A devkit needs to address the elephant in the room and say the device is a devkit and have the features of a devkit.

_________________
I come from the net. Through systems, peoples and cities to this place.


Top
 Profile  
 
PostPosted: Thu Dec 08, 2016 7:56 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
Jarhmander wrote:
Last time I checked, make friend failed on my machine, complaining that there's no rule to make target friend. Where do I find a working Makefile for this?


If only it was as simple as man friend but alas, no such manual page exists. Nor is there one for man woman... *sigh* adulting sucks.

:P

Quote:
It is baffling how frequently these (ARM-based emulators) show up, and use pirated games in the marketing (note screenshots of games that you can not legally buy for the unit alone):
https://www.indiegogo.com/projects/retr ... yer-cool#/
https://retropie.org.uk/


Retropie is purely a software release, they're not selling hardware, nor are they circumventing any licensing (the entire project is hosted on Github). It's basically just taking RetroArch to the next level, where RA combines all of the different emulators together into a unified interface, this packages that along with everything else you would need to set up a dedicated emubox on a Raspberry Pi.

The RE Sigma, on the other hand... yeah that's basically just a Retron without the cartridge ports.


Top
 Profile  
 
PostPosted: Thu Dec 08, 2016 7:57 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2173
thefox wrote:
byuu wrote:
And on a 2MHz system that gets about 300,000 instructions per second, that's not really tenable. Unless you're okay with making an Atari 2600-level game on the NES/SNES.

I don't think "Atari 2600-level" is really descriptive of all the NES/SNES homebrew that has already been made in C.


Wouldn't that be more like 700,000 or 800,000 instructions per second anyway? 300,000 would be like 9-12 cycles per instruction.


Top
 Profile  
 
PostPosted: Thu Dec 08, 2016 8:38 pm 
Offline

Joined: Thu Aug 28, 2008 1:17 am
Posts: 591
Not sure what byuu is taking about. The NES at 1.79mhz is like 450k average cycles a second (assuming 4 cycle average, but it's probably lower than that. Closer to 550k instructions per second). And the z80 reg pairs aren't functionality identical to an "accumulator" reg (matter of fact, a huge majority of operations have to be done through Z80's A reg).

_________________
__________________________
http://pcedev.wordpress.com


Top
 Profile  
 
PostPosted: Fri Dec 09, 2016 2:29 am 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 92
Location: Sweden
Nitpicking aside, neither 65xx nor Z80 is well equipped for efficient compilation of C code.

There are examples of really efficient FORTH implementations for 65xx... I've been thinking a bit if one could make a more easily digestable high level language on top of FORTH that would suit the SNES. Some (optional) type checking and syntactic sugar for flow control and structs (with associated functions/methods) could result in something pretty neat I think.


Top
 Profile  
 
PostPosted: Fri Dec 09, 2016 8:47 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1284
> I don't think "Atari 2600-level" is really descriptive of all the NES/SNES homebrew that has already been made in C.

I do.

> Not to nitpick, but in 16bit mode, the 65816 accumulator is referred to as 'C'

I know, and don't care.

> See ASM with C in it (TCD, TCS). Also XBA (swap high and low byte).

See lda #$1234, tax, pha, etc.

> Both of these things use RetroArch which in turn use things like BSNES, SNES9X, ScummVM and MAME which they circumvent the licenses of the emulators by not including the emulators themselves with the hardware, which is why they don't mention the emulators by name in the marketing either, though you can see them in screenshots.

There's no stopping that, unfortunately. All we can do is implore people not to buy such products.

> So the question is, why is this 60$ device any better than the RetroN 5 or the RetroFreak which can play your legal carts (with the same emulator cores no less)?

The RetroN 5 uses Snes9X without a proper license (there can't exist one: I'm a developer and the code I contributed was non-commercial only.)

In Hyperkin's defense, I believe they're moving to do the right thing. They purchased a license to higan from me, and asked about other cores to license.

> Not sure what byuu is taking about.

It was a quick ballpark number. I keep forgetting where I'm posting, sorry.

Okay guys, here you go:

NTSC CPU oscillar rate: 315/88*6 million = 21477272hz
Standard cycle = ~8 clocks (6, 8, or 12. 8 is the most common.)
Standard opcode = ~4 clocks (2 for NOP, INC; 4-5 for LDA $1234; 6-8 for LDA [$00],Y)
21477272/32=671,164.75 instructions per second, on average

Now keep in mind how many times you have to do two or more instructions for something that most processors can do in one: clc; adc instead of add. asl; asl; asl; asl instead of shl 4. pha; txa; clc; adc #$10; tax; pla instead of add x,#$10.

Point being: the CPU is less than 1 MIPS. Sacrificing most of that to trying to run C on a processor that vehemently opposes such a language is a fool's errand. There are many SNES games that bog down and choke even with well-optimized assembler.

If you want to write a Wheel of Fortune clone, go right ahead. If you want to write a Gradius or Rendering Ranger clone, good luck. If you want the AI in Der Langrisser to take 25 seconds instead of 5 seconds, then go for it.

...

Believe me, I'm with you guys. I want more SNES homebrew. But I'm telling you why we don't have it, and why the Genesis does. You can argue semantics with me, but you can't argue the reality of Pier Solar vs Pac Man.


Top
 Profile  
 
PostPosted: Fri Dec 09, 2016 9:58 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18531
Location: NE Indiana, USA (NTSC)
byuu wrote:
If you want to write a Wheel of Fortune clone, go right ahead. If you want to write a Gradius or Rendering Ranger clone, good luck.

That isn't a stealth jab at me for making something simple like Concentration Room back when I wasn't that experienced with large projects, was it? (well...)

DRW's forthcoming NES game City Trouble (product page; video) is written mostly in C. Or is that likewise VCS-ish?

In any case, with 16-bit A, X, Y, D, and S, and S-relative addressing modes for the group 1 instructions (dd,S and (dd,S),Y), the 65816 is at least less bad for C than the 6502 is.


Top
 Profile  
 
PostPosted: Fri Dec 09, 2016 10:16 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2173
Quote:
There are many SNES games that bog down and choke even with well-optimized assembler.


Everybody says Konami has well-optimized assembly, but I know for a fact that it's not true. Konami's code just looks optimized because of their use of the direct page, but a lot of time is actually wasted moving stuff to and from the direct page that it actually ends up slower than if they just used absolute addressing.

Case in point, their collision subroutine looks optimized because both of the character's coordinates are placed in the direct page when it is being jumped to, but the routine that jumps to the collision routine has to copy the data into the direct page first before jumping to the collision routine.


Top
 Profile  
 
PostPosted: Fri Dec 09, 2016 10:32 am 
Offline

Joined: Thu Aug 28, 2008 1:17 am
Posts: 591
byuu wrote:
> Not sure what byuu is taking about.

It was a quick ballpark number. I keep forgetting where I'm posting, sorry.

Okay guys, here you go:

NTSC CPU oscillar rate: 315/88*6 million = 21477272hz
Standard cycle = ~8 clocks (6, 8, or 12. 8 is the most common.)
Standard opcode = ~4 clocks (2 for NOP, INC; 4-5 for LDA $1234; 6-8 for LDA [$00],Y)
21477272/32=671,164.75 instructions per second, on average

Now keep in mind how many times you have to do two or more instructions for something that most processors can do in one: clc; adc instead of add. asl; asl; asl; asl instead of shl 4. pha; txa; clc; adc #$10; tax; pla instead of add x,#$10.

Point being: the CPU is less than 1 MIPS. Sacrificing most of that to trying to run C on a processor that vehemently opposes such a language is a fool's errand. There are many SNES games that bog down and choke even with well-optimized assembler.

If you want to write a Wheel of Fortune clone, go right ahead. If you want to write a Gradius or Rendering Ranger clone, good luck. If you want the AI in Der Langrisser to take 25 seconds instead of 5 seconds, then go for it.

...

Believe me, I'm with you guys. I want more SNES homebrew. But I'm telling you why we don't have it, and why the Genesis does. You can argue semantics with me, but you can't argue the reality of Pier Solar vs Pac Man.


Well, the difference between stating 300k and 670k is pretty big. I mean, it's as if someone where to come in here and state the SNES base clock speed 1.34mhz instead of 2.68mhz for lo-rom. For someone who has a reputation around the net about being obsessed with accuracy (which is a good thing), it's odd to see you throw out inaccurate numbers/claims like that.

I'm not championing C for these systems either, but I think the assessment of 2600 is a bit of an exaggeration. C for the 68k is sooo much of a better fit. But some of the big problems with C on the 65x isn't so much the smaller details (CLC needed with ADC, etc), but how none of the C compilers can optimize data structures or access to data structures in a way that optimal for the 65x arch. When it comes to speed, it's a pretty narrow window in how data is accessed on the 65x in relation to speed and layout. I'm sure the SNES has it's own issues compounded by the memory layout that adds to this ( long addressing via indirection might seem convenient, but local access with a better memory banking system is more efficient).

I would personally never want to use C on the SNES. I think you'd be fighting with it more, way more than with the NES and TG16 in C. So I'm not disagreeing with you, but having worked with C compilers and C generated code for the 65x, I just disagree with details of why.

Quote:
Everybody says Konami has well-optimized assembly

What!? Who says this? Like many Japanese companies; great game design, mediocre code efficiency (speed) at best.

_________________
__________________________
http://pcedev.wordpress.com


Top
 Profile  
 
PostPosted: Fri Dec 09, 2016 12:42 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
For what it's worth, overall I agree with byuu's stance on this (i.e. I've never seen C as a practical language on the 6502/65c02/65816 given how the designs and limitations of the architecture). I also agree that the 68K almost certainly is a substantially better CPU for C (or x86/x64 for that matter). All the additional registers, instructions, and addressing modes/features make it a better choice.

Switching consoles for just this paragraph: I think there are some C-based NES games which are pretty cool, but yes, you aren't going to find anything like, say, Gradius 2 in C on the NES -- or if you do, all the key/critical innards are done in native 6502. C has just too much "overhead" on the 65xxx architecture.

I don't write C compilers or look at their innards, but the limiting factors with the CPU architecture have nothing to do with the SNES's memory models (mode 20/21/25), although you probably would want mode 21/25 for a linear memory map, though the trade off is that MMIO register accesses take longer (you either use 24-bit addressing or you're going to be doing phb ... plb a lot), and the lda #$2100, tcd trick probably isn't going to help you either (I imagine C compilers on the 65816 make heavy use of DP).

I feel like a broken record saying this, but for the 65816, there are actually two C compilers that I know of: Toshi Morita's lcc816 and ORCA/C for the Apple IIGS. I can't remember if cc65 can be used either, but I do know ca65 has some very annoying design quirks/issues with 65816 that make it painful (I can't find the link on the forum, but we've discussed it before). lcc816 outputs code intended for ORCA/M (Apple IIGS), because Toshi did a lot on the IIGS (he's a guy I met back in 1993 and spent an afternoon/evening around). If you want to talk about "C compiler design for 65816" (since this thread is about the SNES, hence 65816), then Toshi might be a worthwhile person to ask, especially given his background (read, don't skim -- you will find several compilers he's worked on). (Injected note: I feel lucky that I still have my ORCA/M data around, as the Syndicomm website seems to be completely MIA at this point. That Opus ][ product is probably the best bet for getting your hands on it). If I remember correctly, and this is key, the ORCA/C manual actually goes over some of the internals of *how* it was designed/works.

I used ORCA/C on the IIGS for small/worthless projects (back when I was trying to learn C) and because it was the compiler used as part of the Apple IIGS's UNIX OS called GNO/ME. You'll find that most Apple IIGS projects involved ORCA/M (assembler), simply because, yes, that's right, the 65816 doesn't cater well to C in general. There were a couple games made for the IIGS in ORCA/C, but they were things like Tetris clones and (sorry for downplaying the complexities) "simple" games. For anything highly complicated and needed every cycle, assembly was the go-to. There were LOTS of great games on the IIGS in assembly. I can't speak for others, but I mainly did everything in ORCA/M (65816) (using Applesoft BASIC or ORCA/Pascal to generate data sets for me, although I did write a CDA in ORCA/Pascal). On the SNES, most of my efforts were done using a PC and cross-assembler, with nothing more than edit.com (QBasic in editor mode); any graphics/layout data I did was all hand-done using .dcb statements.

Did you notice a common theme in my above paragraphs? If not, here you go: the projects done using ORCA/C and similar were done on a system and environment -- the Apple IIGS, usually within GS/OS -- where tools were available (and those which weren't, you made yourself), all the way down to graphics editors (DreamGrafix) and audio tools (Soundsmith), and with tools that integrated with assembly very very well (this is critical/key!). Debugging was possible through a multitude of ways (GSBug, and classic printf-style debugging if you were using something in the ORCA shell environment), etc... Basically none of this is available on the SNES because it's a video game console, not a home computer. (Injected note: the guys who made DreamGrafix -- Jason Andersen and Steven Chiang -- were both co-founders of Tiburon Entertainment (now known as EA/Tiburon) and did all the Madden SNES titles. Jason worked way too much stuff (almost all in 65816), and Steven's now the executive VP at Warner Bros. Games).

So, all that said: the lack of C compiler really isn't what's keeping people from doing SNES homebrew. There's a term for this that I can't recall right now, but it's one of those "convenient excuses" that people use rather than actually putting in the time/effort to do what their heart is set on. The elephant in the room isn't the lack of C compiler, it's that "writing stuff on the SNES is hard". "What are all the registers? OMG", "I don't understand assembly language, it's nothing like Ruby/Python/Node/blah blah", that kind of thing. Consoles, much like arcades, are a completely different world. The potential gamedevs that might be considering the SNES probably come from backgrounds that are PC-centric, using a plethora of tools and languages and frameworks to accomplish their goal. You throw them into an environment that offers none of that and they're like a fish out of water. Why do you think there's such a humongous influx of indie games on Steam/etc. that have "16-bit-like graphics" but are PC (possibly Mac/Linux) titles?

THAT is why people aren't doing more SNES homebrew.

Breaking out of this excuse model is possible. One such example, though for the NES, is forum user JoeGtake2's game Mystic Searches (see The New 8-bit Heroes). He had game development experience prior, but no 6502 or NES knowledge. He set his mind to it, and he's doing it. In C? Nope, in assembly.

So, really, the reality is that people want "a convenient way to make stuff", and like arcades, there is nothing convenient about classic video game consoles when compared to present-day stuff for the PC (in contrast/comparison). The "lack of C compiler for SNES dev" is really not the crux of the matter.


Top
 Profile  
 
PostPosted: Fri Dec 09, 2016 2:14 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1284
> Well, the difference between stating 300k and 670k is pretty big.

And as I explained, 65xx often requires several instructions to do what another processor can in one.

So you can't compare 670K instructions on a 65816 to 670K instructions on a 68000, let alone on an ARM CPU.

I didn't really cover that nuance in my first post, but I thought I did a good job explaining that with my second post.

> it's odd to see you throw out inaccurate numbers/claims like that.

Look at the sheer volume of posts I make. 6000 on my own board, 6000 tweets, 1200 here, all the posts on Reddit/HN/etc ... some of my posts are of lower quality than others :/

> I think the assessment of 2600 is a bit of an exaggeration

It's really not. The only reason things look better is because of the graphical and audio capabilities being superior.

I guess we're just going to have to agree to disagree. But I have a ton of experience trying to wring out every last drop of performance on the SNES through -hard- code. Proportional font rendering, huffman/LZSS decompression, etc.

I also have experience with compilers and the requirements of transforming C code into 65816 assembler. It's not pretty.

> I would personally never want to use C on the SNES. I think you'd be fighting with it more, way more than with the NES and TG16 in C

It would be much more complex to try and take advantage of the P/M status flags efficiently. But it should still be possible to generate better code than with the 6502. But not by a whole lot.

What would've helped a lot was if we had sax,say,sxy (swap registers.) That would've made arithmetic on X/Y a lot less painful than it ends up being in practice.

My second major change would be to turn WDM into a one-cycle penalty prefix to invert the P/M flag of the next instruction. After that, I'd leave P/M clear outside of leaf functions, and use the prefix for when 8-bit was mandatory (which is not all that often. Mostly for I/O accesses or extreme memory contention.)

It still wouldn't be great for C, but that'd make things a lot easier for an intermediate language between C and assembler.

> I feel like a broken record saying this, but for the 65816, there are actually two C compilers that I know of

LordTech also got pretty far with one.

There's no surprise that they exist: the 65816 is Turning complete. It could handle C++17 or Haskell if you wanted. The issue is entirely performance. The translation has so much more overhead because there is only one accumulator.

I love the 65xx, but I don't pretend it's something it's not.

> So, all that said: the lack of C compiler really isn't what's keeping people from doing SNES homebrew.

I believe it's a large part of why there are so many commercial-quality games for the Mega Drive out of China. Fengshen Yingjiechuan alone (stolen music aside) is right up there with Bahamut Lagoon and Der Langrisser in terms of how much fun it is. And of course, Pier Solar.

But yeah, if we made "game dev kits", I think we'd see a lot more homebrew.

Imagine if instead of having closed source, Windows only, ROM hacking tools for specific games like Lunar Magic for Super Mario World ... we instead had engines like ViRGE or modern PC-based RPG Makers for the SNES.

You'd just use bytecode engines, tilemap editors, modify BMP graphics files, drop in music files to transform (hell, use the MSU1 if you want), have all the sound effects pre-loaded and ready to play for you, etc.

You'd need a strong community around each engine. One for JRPGs, one for Zelda 1-like games, etc.

Of course, by setting the bar so low, you'd get flooded with a bunch of shit-quality games, too. See Lunar Magic and Super Mario World for example. But there'd be some great games put out, too.

> it's that "writing stuff on the SNES is hard"

Honestly, having to code in assembler aside, it's not that bad unless you get super fancy.

The Genesis has a simpler VDP, but holy -fuck- is the interface to it a gigantic pain in the ass. It's like a Rube Goldberg machine to write to the VDP. All the address bits are randomly shuffled because you're going through three layers of legacy abstractions and backwards compatibility to access the thing. Lots of latched state where you have to do successive interleaved writes to even -send- second-layer commands to the chip. I still don't have a clue how the internal FIFO stuff even works for it.

In that regard, I'd much rather work with the SNES and just not use all the fancy stuff the Genesis lacked anyway.

The audio ... in complete agreement there. Audio is a massive pain in the ass on the SNES.


Top
 Profile  
 
PostPosted: Fri Dec 09, 2016 6:46 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2173
I feel like most of the instruction set of the 65816 was wasted on 24-bit addressing. If they just kept the 16-bit address bus of the 6502, they could've had a much more powerful instruction set.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 154 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9 ... 11  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 3 guests


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

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