/vr/ - Retro Games

Cartridge data gets treated as ram.
Publishers had the choice of picking low bandwidth speed rom or fast bandwidth speed rom but they cut costs and picked slow rom most of the time.

>>9206582
It was supposed to be backwards compatible with the Famicom. They dropped that idea but were stuck with the CPU. Also that CPU is good, it's just too slow a variant. Same issue happened with the Apple IIGS. It's also not really reasonable to compare performance per MHz between two different CPU architectures, it's more complicated than the base clock speeds.

>>9206582
Nintendo always makes retarded engineering choices like how the NDS had 2 cpus but the main CPU was actually slower than the GBA one unless you ran code in instruction cache which was only 32K IIRC. All while the other cpu which was normally faster was left unused by the official SDK asides doing audio DMA.

Also Nintendo had a dumbass policy to not allow going over sprite per scanline limit because NES flicker was a common criticism at the time. NEC and Sega didn't care which is why Treasure stuck to Genesis.

>>9206590

The CPU is a 65C816 variant, that is also backwards compatible with the NES 6502. The Apple II GS uses the same 16-bit CPU for backwards compatibility with the Apple II. Which also uses a 6502. But I think Nintendo changing the audio chip, probably caused the SNES to lose BC. Check out Project Nested. Which tries to enable some form of partial NES emulation on real hardware.

The original NES only got made because the slanty eyes ripped off American CPUs and then Nintendo forced a desperate company to make them CPUs for a low ball offer

Those got damn gooks at it again

>>9206582
One question. Why Nintendo didn’t used X68000 hardware?

>>9206790
Rotten Korean ripped off every time!

>>9206609
>>9206609
>Nintendo had a dumbass policy to not allow going over sprite per scanline
aha wow I never knew that. Final fight one only ever has 3 characters on screen. Maybe that's why?

>>9206808
Final Final 2 Hard Edition show lot character on screen. However more fun started.

>>9206582
the two problems with it are that it drops every 1 out of 4 bits on sample decode, and that there is no interrupt line between it and the CPU.
other than that it and the S-DSP are great little guys

>>9206804
lyl no Ricoh weren't Korean. but they were having pretty slow sales at the time with a lot of empty line capacity so they could fulfill Nintendo's demands. pretty much all other chip fabs in Japan were booked up and couldn't spare the resources.

>>9206773
Indeed; I've seen that project, very interesting.

>>9206821
I think that was why Sega outsourced the SVP chip to Samsung--nobody in Japan was available. Unfortunately Korean chip fabs weren't quite as state-of-the-art as Japanese ones and they fucked it up and made a chip as flaky as some Commodore ICs.

>>9206590
>>9206773
Imagine SNES have built in IIGS hardware?

>>9206802
The real answer is likely cost cutting. If a 68k cost another $1 Nintendo wouldn't do it when they can get a cloned 65816 from Ricoh for buttons.
But I like to think it was Jap devs not understanding how superior the 68k was. Despite JP developers being comfortable in ASM to the point SEGA didn't realise how important a C compiler was to the west, they rarely actually produced any code that would make you say "wow." They would make good graphics, catchy music and tight gameplay but the kind of things Bongistan born former Amiga developers would bring to the table with their cycle optimised 68k stuff just wasn't in Japan's wheelhouse.
When you consider the basic tasks of running a mario world or secret of mana, the 68k doesn't actually perform significantly better at 7mhz vs. the 65816 at 3.5mhz. Where the 68k shines is in being able to do significant amounts of optimised data manipulation in its large register set to do scaling or polygons or other fun stuff that you just didn't see in japan. So given that they probably simply didn't understand how badly they were gimping the SNES by not using a 68k.

>>9206606
That sounds like every CPU. The Pentium would run slower than a 486 without the instruction cache and so it was rather important to try and keep your inner loops inside a single cache line.
Is the GBA one being faster not just an artefact of the fact that it supported thumb encoding and so you could get two instructions in every 32bit fetch from RAM provided your code was okay with the greatly reduced subset that was thumb? Under normal circumstances where you used the regular 32bit instruction set so you could do actual heavy lifting I imagine it was much of a muchness.

>>9206582
How much of the SNES hardware was actually designed by Nintendo though?
We know from the design documents in the gigaleaks that at least starting with the N64 Nintendo themselves did barely anything beyond controller designs and picking what expensive parts to cut off their systems.
I wouldn't be surprised if the SNES was mostly made by Ricoh or some other company involved in the manufacturing so parts were chosen based on what they had and could easily profit from in large quantities

>>9208016
>you describing cpu primary
I meant this bad boy.

>>9208039
sorry, didn't read your post properly. But what do you mean by using x68000? It was an expensive workstation back in the day, it's not like they could consolise it and sell it for a reasonable cost.

>>9208030
Not really since the ARM7(GBA) runs just fine at about 16mhz, the thing is that the ARM9 takes a lot of time when fetching instructions words from the memory bus, something like 4 cycles instead of 1 so it makes it run at half the speed of the ARM7.
You could alleviate this somehow by using THUMB instruction which are 16bit but still

>>9208030
The situation with the DS is a bit of a clusterfuck.

The main ARM9 was twice as fast or more than the ARM7 inherited from the GBA. ARM9 is only full speed when using 32KB+16KB TCM, while ARM7 is only full speed when using 96KB WRAM. Whenever you hit main memory, performance tanks as expected. ARM9 has 8KB+4KB cache to take the edge off, but ARM7 doesn't. But ARM9 has several bus limitations like forced 32 bit accesses, no burst mode, and extra latency on top of that. I don't know if this only applies to uncached access.

Programming NDS you must be cache aware, GBA there's like a 2 cycle penalty on the worst loads or branches.

>>9208060
>it's not like they could consolise it and sell it for a reasonable cost
FM Town Manty and lesser CD32 kinda did. So why not?

>>9208039
Ace model is workstation dev kit. I say model 1 retailers worth a cheap price at early 1990s.

>>9208064
At least it's a cache. I remember speaking to someone with a GBA dev kit back in 2000 and the thing they were having trouble with was that they needed their code in work ram for 32bit performance, but the provided compiler compiled everything to run from ROM. You could write ASM and copy the code that you specifically .ORG'd to a WRAM location but no one had any idea how you tell GCC to compile the code in the binary to assume a different offset and the SDK didn't have any provided method to copy code. There was only notions that you could provide a linker script to GCC to achieve this, but that's arcane voodoo, not for your average shovelware developer.
I imagine eventually Nintendo provided instructions and a better SDK but I know that guy's company just used THUMB for their games.

>>9208202
>but that's arcane voodoo
there are people that actually understand how compiler toolchains work and are used

>>9208202
>At least it's a cache.
To get full performance you still need to make use of TCM, which is functionally the same as IWRAM. The cache is there to ease the pressure on main memory, but the GBA's equivalent EWRAM isn't proportionately as slow. Also, the GBA having fast executable cartridge ROM reduces much of the need to use main memory.

>I remember speaking to someone with a GBA dev kit back in 2000 and the thing they were having trouble with was that they needed their code in work ram for 32bit performance, but the provided compiler compiled everything to run from ROM. You could write ASM and copy the code that you specifically .ORG'd to a WRAM location but no one had any idea how you tell GCC to compile the code in the binary to assume a different offset and the SDK didn't have any provided method to copy code.
On homebrew devkits that's all taken care for you, you can just annotate with macros to put things in whichever memory you need. The downside is that it limits what you can load and unload at runtime but for homebrews I guess it doesn't matter much. I know NDS has some official solution for loadable binary overlays, but I never used an official SDK so I don't know how that works.

>>9208219
There are people who understand arcane voodoo too, what's your point? You can get through your entire C++ career not knowing STL. I'm not saying I recommend this, but it's not unreasonable for the genius you hired to port Quake to the Saturn not to know anything about linkers.

>>9208226
actually i would very much expect a person hired to port non-trivial code between unique hardware platforms to understand how to cross compile, which critically depends on the linker.

>>9208253
Writing a linker script is specialised knowledge. You don't need to know how to do that to port between any modern platforms.

>>9208253
99% of game code porting is understanding the SDK or register functionality of both platforms to translate between the two. The last 1% is knowing the "UNDEFINED BEHAVIOR" that the previous developer knowingly or unknowingly relies upon that may have a different outcome on your current platform. But even then it's not something you need to know in detail other than to know that such a thing is possible and to look harder if you think myvar/=2 is giving you a different result than the original.

>>9208016
no? and NES code was normally a slopfest. most Japanese coders couldn't touch Manfred Trenz in 6502 skill.

>>9206582
It was a long time ago.
It was fine.
I enjoyed it a lot and it was a hell of a lot more powerful than the Amiga I had before it.
It sold well and had great games.
Why retrospectively try to argue the CPU was not any good this far down the line. The time is long gone.

>>9208287
It really wasn't. SFC came out years later than PCE and MD and had a worse CPU. It limited the games that could be made and resulted in many games having slowdown or less action on screen.

>Use a low power mod of a well understood CPU
>Still a bitch to emulate correctly
Yes. I know it's the custom chips but still.

The GBA managed to be so easy to emulate that they had ones out before the thing was even fucking released.

>>9208202
IIRC you had to do this ram copying shit for cart savedata too.

>>9208294
The RAM copying for savedata was handled by the official SDK. In fact, it was only permitted to access savedata from SDK functions.

>>9208293
>slowdown
>incomplete programmers
RR D2 all fine though lowROM

>>9208276
>>9208359
This.

oh no this fucked up shitty chip runs some of the greatest games of all time

>>9208652
You mean the SA1 chip runs the best games. SNES carts were more than just roms, they were packed with added cpu power to compensate for the original hardwares limitations.
>Similar to the 5A22 CPU in the Super NES hardware, the SA1 contains a processor core based on the 65C816 with several programmable timers. The SA1 does not function as a slave CPU for the 5A22; both can interrupt each other independently.

>10.74 MHz clock speed, compared to the 5A22's maximum of 3.58 MHz
>Faster RAM, including 2 KB of internal RAM
>Memory mapping capabilities
>Limited data storage and compression
>New DMA modes such as bitmap to bit plane transfer

SNES was carried by the expensive special chips that did the important things that the console CPU could not. It relied on various chips right from day one (pilotwings with its mass coprocessor chip).

Some consider this the reason they shied away from a CD rom early on, since the carts did so much of the workload on their own and a rom from a disc couldnt offer any of the necessary performance boost, unless they simply moved all that extra specialized hardware and powerful cpu into the disk drive itself and let the peripheral drive do all the work.

>>9208806
Maybe 5% of released SNES games used expansion chips. You didn't need anything but ROM to play Chrono Trigger DKC, Super Metroid or Megaman X.

Anyway, prerelease information about the CD add-on suggests that it would indeed have contained its own faster CPU and RAM.

>>9208226
I can 100% fucking guarantee that the lobotomy guys knew how to use a linker lol

>>9208815
All great games.
-Chrono trigger was a turn based RPG, but they took a lot of shortcuts like freezing all idle animations during combat (party members and enemies were all static during combat except for the single active unit doing an action). Something like star ocean which was an RPG with real time combat, and it needed one of the most advanced chips ever used on the SNES so that all party members and enemies could move and fight at once. That was the same chip as SF alpha for SNES but came too late in the console life to matter
-DKC is using sprites from per-rendered artwork and looks amazing for the era, but it uses far less enemies on screen than you see most 16-bit era platformer games. Very rare to see more than 2 enemies on screen at a time, and if there are they are all the identical enemy (like the swarm of birds). The scrolling speed is impressive by SNES standards though, especially with barrel launchers. Very impressive end result.
-Megaman X has the classic slowdown but that is what gives the older games their charm I guess. Megaman X2 and X3 used the 20mhz CX4 chip from capcom

Super mario RPG, Mario cart, pilotwings, Doom, starfox were all only possible with added chips. but having that option let the SNES linger well into the next generation.

>>9206802
>>9208016
>Super Nintendo with 20mhz, better sound card, more vram, more color and hiRES.
VGH…what could had been

>>9208276
>most Japanese coders
You mean all.

>>9208652
But Flashback and Cannon Fodder are much better on the Amiga.

>>9210238
>furshit
>much better
Great joke.

>>9210252
You mean starfox? Or pink bunny link?

>>9210281
Rent free

>>9206582

Street fighter 2 turbo plays extremely fast try putting in the 10 star code, other games can crawl... I'm not smart enough to talk tech shit anymore but super fast gameplay on the system exists

>>9210289
You mean that american furfaggot eric schwartz living rent free in your head?

>>9210291
Fighting games are DMA dependent, not CPU dependent.

What's about that slowROM and fastROM deal? Does it make a big difference?

>>9210296

Elaborate

>>9210296
Why is that? Sprite streaming?

>>9210307
Yeah, fastrom is about 33% faster. Doesn't close the gap with PCE or Genesis though.

>>9208806
Could there be a RAM cart that couple as a co-processor for the CD-rom addon? It would boost the price, but the performance leap and reduced costs for developers could put the Super Nintendo a few steps ahead of the generation. Almost like a 4.5th gen.

>>9210393
The CD ROM add-on would have connected to the base system using a cartridge containing a new CPU and lots of RAM.

If it had come to market in a timely manner, I definitely could see it working.

>>9210393
Like a segacd/32x combo, but for the snes. Would have been neat.

>>9210443
Sega CD already added a lot of extra processing power. Too bad about the bottlenecks.

>>9210402
Super FX 3?

>>9210450
If only the segacd could unfuck the color limitations of the genesis. 60 or so colors onscreen made the already limited FMV even worse. It would have helped so many other games as well.

>>9210573
SNES had indeed good fmv quality.

am i the only one on /vr/ that has written a driver and programmed bgm for the SPC700 and S-DSP?

>>9211278
Yes. Now you are king of /vr/. Give orders, please, sir.

>>9211367
We demand that /vr/ takes an active interest in the technical side of the retro hardware they love to help preserve and extend that art (and so we can have better discussions on the subject)
it is super interesting and fun.

>>9208016
I don't think Nintendo cared. They come from a perspective that they make cheap home amusements. Also they probably perceived NEC as a bigger threat than Sega. NEC already released the Turbo NES 16. Sega choose to release a gimped Sega arcade machine. In the race to the bottom who made the nicest machine... Well, I would say SNK and they were pretty far from being the biggest winner.

>>9208039
Looking Sharp.

>>9206816
Hello sir

>>9206802
Because 68K is expensive as shit and they were trying to maintain BC and didn't want to go back to the drawing board, even after they had abandoned the idea.

>>9208016
What on Earth are you talking about? "Jap" developers absolutely knew the power and versatility of the 68K, half of their arcade hardware and PC hardware ran the fucking thing. You have to be 13 to post here dude.

>>9208034
Nintendo designed the SNES, this is well documented.

>>9208135
The Marty was 98,000 yen at the time of its release, that's why. That's like 4x what a SNES cost. 13. To post here. Jesus.

>>9211453
King, we are too dumb and know only basics of computer. Please, is there any material for dummies?

>>9211717
>68K is expensive as shit
$15 by fucking 1984. 68K was cheap as dirt. It was probably $5 when the snes went into production. Expecting the snes to have BC is a quite sound reason though.
>half of their arcade hardware and PC hardware ran the fucking thing
Relative to the westerners, who made full 3D open world games run on 7 Mhz amiga, they weren't all that skilled.

>>9212220
$15 per chip, now scale that to millions of units. Costs add up. The POS 65C816 they used in the SNES was likely much cheaper.
I wasn't arguing that Japanese coders were Carmack-level geniuses, only that they were familiar with the 68K. It was not in any way foreign to them.

>>9212226
LESS THAN $15 per chip. Well of course the 8 bit piece of shit is even cheaper, but at what price? Just hike up the console unit price, $5 increase wouldn't hurt.

>>9211453
Come over /hbg/

>>9206582
>How bad did Nintendo fuck up with this weak ass cpu
they didn't fuck up at all, you stupid cunt.
>put the genesis to shame
that never happened.
> it was half the speed
entirely different cpu too, but you'd know this if you weren't a retard.
> the rest of your post
absolute cancerous nonsense.

>>9206590
>It was supposed to be backwards compatible with the Famicom
i love how nintendo and their fanboys just reinvent history. no, nintendo started using the 65816 because:
https://en.wikipedia.org/wiki/Gunpei_Yokoi#Lateral_Thinking_with_Withered_Technology

so.. no. nintendo weren't ever going to use anything more powerful than this cpu.

>>9211717
>What on Earth are you talking about? "Jap" developers absolutely knew the power and versatility of the 68K, half of their arcade hardware and PC hardware ran the fucking thing.
it's factual. by mid 1980s, most jap arcade systems were moving from z80 to 68000.

>>9212331
>Well of course the 8 bit piece of shit is even cheaper, but at what price? Just hike up the console unit price, $5 increase wouldn't hurt.
it's a good thing you low iq monkeys don't run a business. you have no idea how basic economics works.

>>9212220
>>9212226
>NES playback
Never happened. Nintendo run by stupid ceo. They can co-work with Sharp X86k.

I think Nintendo didn't want to just use the same CPU as Sega or it would look tryhard. Also by that point there were lots of experienced Famicom coders around who knew 6502 asm so the transition would be easy.

>>9212671
>lots of experienced Famicom coders around who knew 6502 asm so the transition would be easy
Funny enough, same dev (western too) who more useful to 68k assembly. Nintendo just bought themselves laziness or greed.

>>9212220
>$15 by fucking 1984. 68K was cheap as dirt. It was probably $5 when the snes went into production.

Surprisingly, actually cheaper. In the March '91 Dataquest report it states that an 8mhz 68000, when purchased in volumes of 25,000 units, cost $3.32 per in 1990. Scaled to SNES production amounts I'm guessing Nintendo could have secured it for under $3. Ricoh was probably able to produce the '816 for under half that amount considering the die size difference.

>>9208202
>linker script to GCC to achieve this, but that's arcane voodoo

Yeah no kidding. I had to deal with that mess once and I started seriously hating GCC and all the fucking assumptions it makes. And this was for the very much standardized and well known ELFs, can't imagine the hell people went thto build some GBA ROM.

>>9211453
>>9211278

Roger that, elder wizard king. If I may request some pointers on how to get started? I've written some Linux drivers for my laptop but nothing retro.

>thought someone did amazing work of updating sound on snes cart
>just streaming pcm files making the romset like 500mb+

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

>>9213154
For me, naturally zx super nes screen

(loud warning) https://m.youtube.com/watch?v=9oeGLvkskPs

>>9212612
>factual
>moving from z80 to 68000
Source?

>>9211717
>To post here
You not bright?

>>9212612
>it's a good thing you low iq monkeys don't run a business. you have no idea how basic economics works.
It was three fucking dollars. Maybe like $1 more expensive than the 6502 shit they ended up using. Whats wrong with selling your console for $191 instead of $190???

Bump

>>9211597
Nintendo should pretty care far more
See explain>>9208039

>>9206590
Same issue?