[ 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: 27 KB, 800x600, super_everdrive_deluxe03.jpg [View same] [iqdb] [saucenao] [google]
2295415 No.2295415 [Reply] [Original]

Can someone explain to me why flash carts are not considered emulation?

I understand that they run the rom on actual hardware, but am looking for a deeper explanation

>> No.2295421

>>2295415
>they run the rom on actual hardware

>> No.2295423

Because they run the rom on actual hardware.

>> No.2295428

If you run them on the actual hardware then you're no running them on emulated hardware, therefore it's not emulation.

>> No.2295431

>>2295415
>I understand that they run the rom on actual hardware
k

is there any good flash carts that will let me play sonic 3 complete?

>> No.2295432 [DELETED] 

>>2295415
Emulation typically means you're attempting to mimic or recreate how the original hardware handled specific code (the game). The game is the same, whether it's on an SD card, flash cart, USB drive, etc. The important part is how that code is interpreted. Emulator typically involve a combination of reverse engineering, documentation, guesswork, and general programming skill. Not to mention that the emulator can produce wildly different results based on the hardware and OS it's running on. The game code is always the same, and is never technically emulated.

You're asking a semantic question, Anon-kun. But know that it's the console's behavior that is being emulated, not the games themselves.

>> No.2295434

>>2295415
pretty sure the big difference here is that it's running the ROM on actual hardware.

>> No.2295437

>>2295421
>>2295423
>>2295428


Some people might say that they are "emulating" a real cart though. Not that I agree with that, but what are your thoughts on the matter

>> No.2295439

>>2295431
it plays on both of krikzz' genesis/MD everdrives

generally, most rom hacks work on original hardware except for N64 rom hacks (due to expanded rom images, etc)

>> No.2295440

>>2295431
sonic 3 complete wasn't designed to run on a sega genesis though. it's not a genesis or megadrive game. (unless someone can build a special cart that encompasses it)

>> No.2295443

>>2295439

didn't work on mine. i'll try patching again

how long should it take to load?

>> No.2295446 [DELETED] 

>>2295440
It totally works on a flash cart just fine.

>> No.2295448

>>2295439

it didnt work on mine. how long should it take to load? I'll try repatching

>> No.2295449

>>2295440
It is a genesis game. It's a ROMhack of the original. It's not like some fangame engine or anything. Putting a ROM of it onto a flashcart works just fine.

>> No.2295450
File: 296 KB, 490x361, 1409073235786.gif [View same] [iqdb] [saucenao] [google]
2295450

>>2295440
what are you talking about?
you take the rom and patch it...

picrealted

>> No.2295452

>>2295446
>>2295448
>>2295443


woops repost. I'll have to try patching it again tho. thanks

>> No.2295453

>>2295446

>>2295449
>>2295450

im retarded and must have just downloaded a shitty prepatched version.

>> No.2295454

>>2295448
i got it prepatched (in a giant rom hack pack) and it worked on my edmd v3

>> No.2295473
File: 14 KB, 400x300, patton_oswalt.jpg [View same] [iqdb] [saucenao] [google]
2295473

>>2295437
"Emulating a cart" doesn't make any sense, really. There is no difference between an Everdrive and an actual cart, technically speaking. Underneath that cart, the same ROM is there, waiting to be loaded and played. Using an Everdrive just means you have a cart that can load any ROM you want, and each ROM is assumedly ripped straight from an original cartridge. There is exactly zero difference.

Emulating the actual hardware is a HUGE difference. Emulators are built by reverse-engineering the console itself, through all manner of hacky shit. Honestly don't know how people do it entirely, but I assume it's probably by analyzing ROMs and seeing what system calls are made and what the expected behavior is, along with knowledge of the hardware itself.

The caveat is that these emulators wind up being inaccurate in several ways, whether it be framerate, sound, resolution, etc. Whatever it is. Emulator accuracy is a huge deal to a lot of people, and the best way to avoid having to deal with an Emulator is just to play on the original hardware to begin with.

>> No.2295478

>>2295415
>not sure if trolling or just autistic

>> No.2295481

>>2295478

Not my opinion, I got asked this question by someone and didn't know how to explain it fully

>> No.2295484

>>2295473

This is what I was looking for. thanks.

Anymore input on the technical side of things is appreciated

>> No.2295549

>>2295428
Except when you emulate on the original hardware.

>> No.2295604

>>2295473
>>2295432

this was the guys reply

"Whether it makes sense to you or not, a flash cart most certainly is a device that emulates the functionality of the hardware found in original cartridges. It's less apparent in the case of PCE hucards, which are comparatively simple, but it's quite obvious when it comes to NES or SNES games (flashcarts don't have dozens of real add-on chips on board)."

>> No.2295628

>>2295604
http://en.wikipedia.org/wiki/Emulator

Since you're using the original hardware, its not emulation since emulation is forcing another system to behave like another via software (and sometimes hardware). If you're using an NES, and have an NES flashcart, you aren't emulating. You're playing NES on an NES.

People need to stop thinking of Flashcarts as these weird things. They're just programmable multi-carts.

/vr/ has gone to shit these past 3 months or so. Its time I find somewhere else.

>> No.2295631

Emulators run the games code on a virtual machine, on another system

Flash Carts mimic the hardware of a cartridge using the games code and a custom cartridge, on the original system

>> No.2295635

>>2295604
What do add-on chips have to do with it? SNES games that use extra chips aren't supported with flash carts anyway, so it's not like the cart is emulating those chips.

>> No.2295645 [DELETED] 

This whole thread is eerily similar to what it's like trying to explain things to my bipolar little brother when he's in one of his manic phases.

>> No.2295646

>>2295604
my resposnse:

It doesn't imitate the function of an actual cart though, it replicates it. The console hardware is reading the exact same data as an actual cart. Seems more of a semantic issue to me - I think it's most common that people refer to emulation in gaming as console hardware reverse-engineering to run on new PC hardware. This introduces error to the game playing experience. So I don't think "emulation" would be the proper way to describe flashcarts.

And for the special chips, flashcarts are getting better. SD2SNES almost covers all of the special chip games now. If someone was so inclined they could butcher carts for the original special chips and make a flashcart with full compatibility from my understanding. For those few that aren't compatible, then they may be worth buying until flash carts catch up. Usually not considering the price though, imo.

>> No.2295649

In the case of NES flashcarts, there often is some software emulation going on of the addon chips. Anyone who tries to pretend that isn't emulation is lying to themselves.

>> No.2295651

>>2295646
his response:

Look up the definition of hardware emulation. *rolls eyes emote*

The fact is that original cartridges do not function in the same way that flash carts function. Something like a chucard replicates an original huey, whereas a flashcart emulates them.

>> No.2295652

>>2295651
my response:

In integrated circuit design, hardware emulation is the process of imitating the behavior of one or more pieces of hardware (typically a system under design) with another piece of hardware, typically a special purpose emulation system.

[-X
Look up the definition of imitation. Flashcarts replicate the function of original carts

>> No.2295654

>>2295652
His response:

Right, because hucards boot to a menu, use microcontrollers that allow them to read serial memory, and load games into onboard ram instead of allowing the console to run it straight from the rom. :roll:

Flashcarts replicate the functionality of the original cartridge, true, but they do it by emulating the hardware found in said cartridges. Did your mom drop you on your head a lot? :lol:

>> No.2295658

>>2295646
Are clone consoles considered emulation now?
How are pirate cartridges not reverse engineered?

>> No.2295668
File: 92 KB, 1395x1442, MO_OLYMPUS_OL-D640.jpg [View same] [iqdb] [saucenao] [google]
2295668

>>2295415
It's not emulation, it's a COMPONENT SUBSTITUTION, console kid!

It's got less in common with emulation than when nintendo swiped away the RCA video jack with the NES-101.

>> No.2295675
File: 39 KB, 800x450, powerramp-IMAG0235.jpg [View same] [iqdb] [saucenao] [google]
2295675

>>2295668
It's like calling most joysticks, and especially arcade sticks emulation, when they're often closer to the original controls.

>> No.2295681
File: 462 KB, 758x1050, royalseal.jpg [View same] [iqdb] [saucenao] [google]
2295681

>>2295675
It's like calling the trackball on this thing an emulation of a mouse, when the whole point of it was that it was NOT an emulation of a mouse, just a close substitution, decreasing compatibility.

But then, it actually could emulate a mouse, increasing compatibility. Just as an arcade stick might emulate a keyboard.

>> No.2295698

Can someone explain to me why bootleg carts are not considered emulation?
I understand that they run the rom on actual hardware, but am looking for a deeper explanation

>> No.2295703

honestly who gives a shit
unless you're collecting, it shouldn't affect you're enjoyment in any way

>> No.2295704

>>2295675
What original controls on an IBM compatible? The keyboard on the 5150?

>> No.2295709
File: 78 KB, 702x734, 3rd party.jpg [View same] [iqdb] [saucenao] [google]
2295709

>>2295681

>MadCatz

EVERY TIME

>> No.2295712

>>2295698
Bootleg carts are still carts. No emulation or hardware workarounds are taking place for the game to operate properly, excluding necessities to bypass lockout chips or whatever.

Emulation is essentially a console or pc of any kind that lacks the specific hardware of the console, and uses other methods through software in order to perform simulated actions in as close to the same way as the original console as possible.

>> No.2295717 [DELETED] 

>>2295698
>Can someone explain to me why bootleg carts are not considered emulation?
mindblown.gif

I can only assume you're trolling, several people have given good explanations up thread.

>> No.2295735

>>2295717
>>2295712
That was a joke. Sorry, I'll remove myself from the thread.

>> No.2295743
File: 493 KB, 1600x1200, MCN64_57.jpg [View same] [iqdb] [saucenao] [google]
2295743

>>2295681
But most joysticks, ones not quite like the 'XL, would be insulted to be described as "an emulation of the saturn 3d gamepad" or somesuch.

>>2295704
Original controls *for the specific game*. Context!

>> No.2295781
File: 552 KB, 1179x786, frag2.jpg [View same] [iqdb] [saucenao] [google]
2295781

>>2295709
Hey buddy, check this shit out!!

We've been salvaging some real neat old machinery, re-purposed old embedded music systems, and hacking them like you wouldn't believe! They're really cool they have OPL4 chips, you might say they're emulating a "genuine soundblaster", but if you're gonna say "naw dude, I'd rather play on my genuine Intel Pentium system complete with a bona fide soundblaster PCI64" you'd be in the wrong to scoff at our alleged emulation. Now, the only issue is that they don't have any PS2 ports or anything like that, just a whole ton of DB15 ports, but we've got this unbelievably awesome reactOS abstraction layer that lets us use lotsa controllers! Now, I know you hate madcatz, so we're gonna let you use this frag master thing here instead, howaboutthat?

>> No.2295783

>>2295781

I kinda want to try this, I'm having a hard time fathoming what the hell is going on.

>> No.2295801

>>2295783
It's the one type of situation where a common temptation to use a "cool story bro" response would get defective, because that would come out completely backwards.

>> No.2295804

>>2295783
Want to try what? Gaming on a hacked embedded system or using a fragmaster?

>> No.2295817

>>2295804

Playing a fragmaster.

I have a fascination with bizarre controller concepts.

>> No.2295825
File: 76 KB, 640x479, P1010009.jpg [View same] [iqdb] [saucenao] [google]
2295825

ask that jabroni is he thinks this is 'emulation'

>> No.2295828
File: 153 KB, 2357x2012, Spaceorb360-3small.jpg [View same] [iqdb] [saucenao] [google]
2295828

>>2295817
Huh, bizare-concept controllers?

Hold on there, let me just look into my bizarre-concept-controller folder rather than my way-below-bizarre-concept-controller folder

>> No.2295832
File: 29 KB, 450x450, Cyberman2.jpg [View same] [iqdb] [saucenao] [google]
2295832

>>2295828

>> No.2295837
File: 59 KB, 502x481, logitechwingmanwarrior2mn7.jpg [View same] [iqdb] [saucenao] [google]
2295837

>>2295832

>> No.2295845

>>2295651
>>2295652
>>2295646

You should introduce him to /v/. His level of intellect would help him fit in quite nicely there.

My Response: NOT YOUR FUCKING BLOG

>> No.2295846
File: 17 KB, 620x398, 95.-Microsoft-SideWinder-Dual-Strike.jpg [View same] [iqdb] [saucenao] [google]
2295846

>>2295837

>> No.2295851
File: 8 KB, 248x250, Gravis Xterminator DualControl.jpg [View same] [iqdb] [saucenao] [google]
2295851

>>2295846
>>2295817
>>2295837
and this one isn't even properly bizarre, and Gravis was too late to the alternative FPS controller game to qualify as conceptual, but it fits with the gameport FPS controller theme.

>> No.2295857

>>2295709
Unfortunately, thems classic FPSes had a nasty habit of being without a split screen mode.

>> No.2295863

>>2295628
>/vr/ has gone to shit these past 3 months or so. Its time I find somewhere else.

Calm down, anon. flashcarts have always had detractors.

>> No.2295903

>>2295846

goddamn Sidewinder was so hyped up, I remember seeing that shit everywhere.

>> No.2295940

>>2295845
he's the mod there. also sorry for the blog post

>> No.2296082

>>2295863
No its every single fucking thread.
More and more threads are just blatant trolling and everyone falls for it.

>> No.2296160

>>2295628
>/vr/ has gone to shit these past 3 months or so. Its time I find somewhere else.

People have been saying this board has gone to shit everyday like the month after it was created. You're all too quick to throw it under the bus whenever you see the smallest thing you dislike. If you want we can really make this board shit by just discussing twitter posts everyday like a certain other video game board.

>> No.2296214

>>2295604
That's "emulating" in the sense that I sit down and play NES on an old TV to emulate the experience of playing video games from my childhood.

When discussing emulation, we're talking about emulating the console. Saying a flashcart is emulation is like saying playing burned CDs on dreamcast is emulation.

>> No.2296226

>>2295415

Think of it this way.

Can your CD player tell any difference between a CD-ROM bought from the store and a CD-R copy you made of that CD-ROM?

No. The data is exactly the same. Bit for bit.

It's the same with a flash cart. Once the ROM data is loaded into the flash cart's memory banks the system can't tell the difference between it and the "real" thing.

>> No.2296246

Hardware emulation means software behaves in a way which emulates hardware. The hardware is there with a flashcart so usually no emulation happens. "Usually" because there are sometimes extra chips on cartridges like the Super FX chip. In this case a flashcart has to emulate it.

>> No.2296296

You couldn't tell the difference between an emulator displaying to a CRT (using correct resolutions) and real hardware displaying to the same CRT 99% of the time.

>> No.2296301

>>2296296
That depends on the emulator.

>> No.2296319

>>2296082
I haven't in this thread, but I for one wouldn't shitpost so much if the majority of /vr/ users were able to use Google.
People would read & learn how to do things instead of coming to mommy /vr/ to figure out how to turn their console on out where you plug the controllers in.

>> No.2296326

>>2296296
As long as both are displaying a black screen you're right!

>> No.2296331
File: 941 KB, 1000x717, 1402450220247.jpg [View same] [iqdb] [saucenao] [google]
2296331

If the flashcart is directly feeding data in the same matter as the original hardware then it’s neither. It’s simply hardware at that point. Guess you could call it a repro.

“Emulation is what we do when we try to make one system behave like or imitate a different system.”

“Virtualization is a technique for using computing resources and devices in a completely functional manner regardless of their physical layout or location.”

~Computer World
http://www.computerworld.com/article/2551154/virtualization/emulation-or-virtualization-.html

Emulation is what you play on the PC.
Virtualization is what a flachcart does. An example being N64 EverDrive which takes all the roms and puts them into a menu to choose from. Certain things are changed but it’s the ones and zero of the rom that are in a real game and the real hardware is playing it.

>> No.2296368

>>2296082
if you actually read the thread you'd understand there is no trolling going on

>> No.2296563

>>2295781
That thing looks pretty fun

>> No.2296593

>>2295646
>SD2SNES almost covers all of the special chip games now

>only covers C4 for Rockman X2 and the GODFUCKAWFULE ROCKMAN X3 and the shitty SD-1 for Mario RPG and Top Gear 300
>there hasnt been an update for Super FX for more than a year since last time
>not even SA-1 so we can play Super Mario RPG in english without resellers, playing Kirby Super Star, Dreamland 3, Hyper Dimension, Oshaberu Parodius, etc.

>> No.2296603

>>2296296
I could, but I am an expert in such matters. You are correct that 99% of people could not tell the difference.

>> No.2296827

>>2296603
>I am the 1%
isn't that special

>> No.2296828

>>2295437
>Some people might say that they are "emulating" a real cart though
anyone that would say that is fucking stupid and should not exist.

>> No.2296837

>>2295863
that may be true but I personally have never seen anything as stupid as "it's emulating a real cart" before, also this board as a whole is getting more typical 4chan garbage, memes from /v/ and /b/ are seeping in along with the over all hateful and trolling nature of those boards

>> No.2296838

>>2296319
blaming other people for your CHOICE to shitpost is a retarded excuse and is just meant to push the blame away from you anyhow

>> No.2296940

>>2296838
blaming other people for your CHOICE to always cry for help is a retarded excuse and is just meant to push the blame away from you anyhow

>> No.2296959
File: 6 KB, 300x158, chief_arino_by_agentruble-d816am6.jpg [View same] [iqdb] [saucenao] [google]
2296959

>>2296940
but no one was talking about asking for help... and that isn't something /vr/ generally cares about unless it's something retardedly simple anyhow..

>> No.2297928

>>2295781
I dont get it. how does it work

>> No.2297990
File: 22 KB, 210x330, jan_jansen_631.jpg [View same] [iqdb] [saucenao] [google]
2297990

>>2295801

>> No.2298048

>>2296827
This is what people mean when they say /v/ is leaking.

>> No.2298359
File: 35 KB, 250x250, SGRLTS_m.gif [View same] [iqdb] [saucenao] [google]
2298359

>>2297928
Well, essentially, a whole lot like the titans sphere!

>> No.2298362

>>2295415
Emulation means you're EMULATING the hardware - running a program that pretends to be hardware.
If they're running it on hardware, it's not emu.

>> No.2298379

After a lengthy discussion on another forum, it seems like hardcore collectors are prone to consider flashcarts as emulation.

Their reasoning was because the hardware of a flashcart is "emulating" the maskrom hardware of a real cart.

They are citing the definition of hardware emulation.

I know it sounds silly as hell, but that community is loaded with hardcore collectors

>> No.2298382

>>2295481
A flash cart is like putting gas in your car. Emulation is like building a whole new car from the ground up.

>> No.2298383

>>2298362
They aren't passive electronics. They're running their own programs.

>> No.2298398
File: 27 KB, 725x700, battle-zoom.gif [View same] [iqdb] [saucenao] [google]
2298398

>>2298382
Whoa, that really depends on what you mean by "gas"!

Flash carts are like finding yourself someplace where gasoline is horribly inaccessible but the propane supply happens to be really good and converting your car for LPG. Emulation is like having an electric car.

>> No.2298403

>>2298398
>>2298382
Emulation is like driving a transformer.

>> No.2298410
File: 11 KB, 220x180, 2572-1.jpg [View same] [iqdb] [saucenao] [google]
2298410

>>2298398
A retron on the other hand is like kludging an idiotically heavy military vehicle shell on a chevy Tahoe chassis!

>> No.2298412

>>2298410
As long as your wife likes it.

>> No.2298430

>>2298410
>>2298412
Whoa, the original caption for that pic

"In the past few years their has been an explosion of these beasts in Southampton. I pass at least 10-15 of these a day. Mostly driven by 90 pound trophy wives of the rich, who make up most of this town."

Kinda surreal, guess it really is like a hummer h2, except of course many orders of magnitude more measly than any sort of car.

>> No.2298453
File: 670 KB, 800x1199, 1419202242562.jpg [View same] [iqdb] [saucenao] [google]
2298453

>>2298410
when i was 19, i was driving my familys H3 on the highway in the heavy rain, getting road head from a country slut...i rear ended someone bad, and ran away...it still haunts me...still came though

>> No.2298464
File: 2.00 MB, 296x339, 1425939862971.gif [View same] [iqdb] [saucenao] [google]
2298464

>>2295681
>>2295743
>>2295709
Shit like this makes me wonder what happened to MadCatz? They used to make nothing but hot garbage but now they're the go to dudes for Arcade sticks

>> No.2298470

>>2298464

They bought out Saitek and finally got an engineering team.

>> No.2298481

Ok real talk

I need to know what is the best Flash Carts for

NES
SNES
N64

and any other suggestions. I value your knowledge /vr/

>> No.2298487

>>2298481

snes - sd2snes

n64 - everdrive

not sure on nes

>> No.2298491

>>2298487
The SNES Everdrive ain't better?

>> No.2298496

>>2298487
64drive is better

>> No.2298497

>>2295415
It's been said already but...

Look up the definition of "emulate"

>> No.2298503

>>2298481
>reproduce the function or action of (a different computer, software system, etc.).
>"the adaptor is factory set to emulate a Hercules graphics board"
But some people on this board seem to think emulation only refers to video game console emulator software.

>> No.2298672
File: 43 KB, 500x400, 1408069323967.jpg [View same] [iqdb] [saucenao] [google]
2298672

>>2298496
Not to be rude, but, nigga you retarded.

>> No.2298982

>>2298481
With the exception of SNES, Everdrive the best for all available. The real trick is picking between EverdriveMD V2 & V3. And deciding on cheap SuperEverdrive China Ver w/ DSP chip or expandable SN2SNES.
Powerpak is a relic with no new support for nearly five fucking years. Get over it.

>> No.2299010
File: 73 KB, 800x600, everdrive_chinaver.jpg [View same] [iqdb] [saucenao] [google]
2299010

>>2298491
No. At best it only supports DSP games, with a DSP chip soldered in. The only real perk is that it can be had for 66 dollars.While theoretically SD2SNES can support any specialized ship games, theoretically because the assclown behind it is taking forever to code the shit. CX4 has been running overclocked for how many years now? Cheat codes, SuperFX & SA1 support fucking when? Right now the coolest feature is support for Byuu's MSU1 code. Honestly, I'm amazed that no one has taken his source code and started to fix or work on this shit on their own. Aww, but that'd require some real programmers and not some cocksucking faggot, like Drakon, gloating about how much of a script kiddie he really is.

>> No.2299524
File: 375 KB, 1074x718, Graphicsblastertnt.jpg [View same] [iqdb] [saucenao] [google]
2299524

When creative labs released/bundled a glide wrapper with their riva TNT cards, they got a bit defensive about it not being emulation software.

>> No.2299548

>>2295437
simulation and emulation are not the same thing.

>> No.2299575

how is this thread still here?
guess there must have been an influx of people making harmless jokes in a GCCX keeping the janitors busy for the last 3 days...

>> No.2299578

>>2299010
I fucking hate drakon! I want to kill him!
Hey I released this cool music hack, heres a proff video!
SORYY GIBE MONYS PLZ!

>> No.2299581

Can anybody recommend a good brand of CDRs to emulate games on a modded Dreamcast?

>> No.2299593

>>2299578
at least he is charging for his own hacks, unlike the people that sell "repro carts" of hacks and translations that they did no work on what so ever. Yet the later is much more accepted in the retro gaming community. I'm not sticking up for him or anything, it's just... yeah...

>> No.2299595

>>2298464
Mad Catz (as well as Hori) just uses off-the-shelf buttons and sticks and puts them together. You can do the same thing yourself.

>> No.2299629

>>2299581
>modded Dreamcast
oh shit nigger what are you doing

>> No.2299657

>>2299575
what's wrong with the thread. have you even read it

>> No.2299662

>>2299548
it is technically hardware emulation since flashcarts don't use maskroms.

>> No.2299665

>>2296828
I know right. try telling this to a hardcore collector community. In my thread over on that forum they all seem to see flashcarts as emulation.

>> No.2299681 [DELETED] 

>>2299593
dakon is a fucking assclown, that rips people off, butchers consoles & renders them unrepairable. and if you think he's not selling repro carts too, I got news for you.

>> No.2299687

>>2299593
drakon is a fucking assclown. he charges bullshit prices for console mods, butchers consoles & renders them unrepairable. and if you think he's not selling repro carts too, I got news for you.

>> No.2299701

>>2298464
>MadCatz? They used to make nothing but hot garbage

Huh? I take it you mean during/starting at the xbox-huge era?

>>2299595
That seems like quite a bit more work than merely fixing a madcatz stick though.

>> No.2299709

>>2296331
>Virtualization
THIS!

>Virtualization
>Virtualization
>Virtualization

That's what they called this kind of stuff when it existed ages ago on the PC, virtual drives, even though that was done entirely in software. And virtual machines, paravirtualization, and whatever else.

>> No.2299714

Flashcarts themselves are obviously not emulation and anyone who's not thick as a brick can see that.

Having said that, I'm kinda interested in what's under the hood of SNES flashcarts. Obviously there are the ones that are just straight-up flashcarts, but they have poor compatibility because there were shitloads of SNES games that used coprocessors on the carts. So how do "advanced" flashcarts like SD2SNES handle that? does it have one of every type of SNES coprocessor crammed into it? Does it actually emulate the various types of coprocessors

>> No.2299795
File: 24 KB, 320x240, you lose.png [View same] [iqdb] [saucenao] [google]
2299795

Mfw that thing is for poor collectors who cannot afford the actual carts. Not saying you shouldn't do it but in my personal opinion it is absolutely disgusting.

>> No.2299796

>>2299795
I have a lot of carts and use a flashcart over them. The flashcart you just leave in the console and you can play your games. Also get to play jap games easily which is a big bonus.

>> No.2299804

>>2299796
That is actually pretty good point right there. I guess it's time for me to have a break of purism.

>> No.2299812

>>2299795
>this is what collectorfags really believe

enjoy your emulated fulfillment in the form of plastic and pcbs

>> No.2299992

>>2299812
shhh.
we need him.

>> No.2300058

>>2299796
And with emulation software I can use the same computer for dozens of systems, including Jap computers.

>> No.2300083

>>2299992
For what?

>> No.2300246

>>2298379
Not sure what you saw where but no. This is a a thing "hardcore collectors" are "prone to consider"

>> No.2300249

>>2300058
But with not as much accuracy as playing flash carts on the original hardware. This is the market and purpose for flash carts.

>> No.2301939

>>2299010
but
SD2SNES code is open source

>> No.2301940

>>2298982
what's the difference between MD V2 and V3?

>> No.2301943

>>2299714
boku no FPGA + chip .bin's

>> No.2302032

>>2295415
Mario plays original games on original hardware.
Luigi plays flashcarts on original hardware
Wario emulates on his Thinkpad.

Mario looked at Luigi and said "Fucking pleb. Not spending hundreds of coins to buy the original carts, shameful display. I play the games the way they were meant to be played and therefor I am superior to you."

Luigi looked at Wario and said "Look at this stupid millennial. You don't even own the hardware. I bet you need savestates just to beat the games. I play the games the way they were meant to be played and therefor I am superior to you."

Wario decided to have fun playing video games and not worry about what other people do.

The end.

>> No.2302037

>>2302032
Anything else you'd like to project onto us? You have a whole anonymous audience.

>> No.2302202

>>2301939
No shit. Did your dumbass even read the part where I said "Honestly, I'm amazed that no one has taken his source code and started to fix or work on this shit on their own."?

>>2301940
V3 is a new budget model, while V2 has more features.

>> No.2302401
File: 191 KB, 350x330, Waaaaaaaaaaaaaaaa.gif [View same] [iqdb] [saucenao] [google]
2302401

>>2302032

Then WaLuigi came out and in typical 4chan fashion called everybody an Autist.


Waaaaaaaaaaaaaaaa

>> No.2302896

>>2302032
The similarities are uncanny. Wario is a fat smelly lazy slob who can't get laid. He showed up a good decade after the others and is a poorfag obsessed with shekels. You nailed it.

>> No.2302919

>>2295415

Because a flashcart is like having a magical video game that has all the video games on it. Think of it like running PC games off a harddrive I guess. It's running on its native hardware you just have the option to not have to load in each individual game to play them as they're all in one form of media storage.

>> No.2303839

>>2302919
So a flashcart is emulating a multicart. Got it.

>> No.2303895

>>2296226
But then... Can the original game or the ROM tell the difference between the real hardware or an emulator?

Not trying to be sarcastic here.

Correct me if I'm wrong: an emulator is a bit for bit replica/homologue of the hardware.

>> No.2303896

>>2296837
No shit. We're still in 4chan you know.

>> No.2303902

>>2303895
Some games will have a check to prevent piracy. Most emulators and modern piracy devices are advanced enough to avoid triggering those checks.

>Correct me if I'm wrong: an emulator is a bit for bit replica/homologue of the hardware.
There are no circuit accurate emulators. The best you'll get at the moment are cycle accurate which behave very much like the original hardware would.

>> No.2303915

>This board has gone/is going to hell in a handbasket.
I've been here since day 1, and before that I was on /vg/ since day 1, and before that I was on /v/. 4chan has no "good" boards, some are just less shit than others. /vr/ is one of the least shitty ones. Its level of shittiness has essentially remained constant throughout its existence.

>>2303895
>Correct me if I'm wrong: an emulator is a bit for bit replica/homologue of the hardware.
Think of it this way; is your computer/smart-phone/retro-on-VI a part for part replica of the original hardware? The answer is no, therefor it is not "bit for bit" perfect. Emulation for most /vr/ systems is currently at a point where the output is indistinguishable to a human being from the output from original hardware. If you press d-pad right on Genesis hardware Sanic, he goes right. If you press d-pad right on a Genesis emulator, Sanic still goes right. This is good enough for most people just looking to play games and have fun.

Of course there are loads of exceptions. For example, emulators run Golden Eye with much fewer issues than the actual N64 did, making the game much faster.

>> No.2303932

>>2295415
>Can someone explain to me why flash carts are not considered emulation?

The same way using a CD-RW disc instead of an original one is not emulation.

>> No.2304235

>>2299524
A translation layer that passes function calls to a locally compatible API is generally not considered to be emulation, because no hardware is being virtualized. Glide wrappers for old cards just translated Glide into OpenGL.
See also: Wine Is Not an Emulator

>> No.2304429

I think op might be retarded.

>> No.2304434

>>2303932
That's not comparable. A ROM cassette and a CD ROM are completely different aside from storing read only data.

>> No.2305754

>>2303895
With most emulators it would be trivial for code to figure out if it was running in an emulator. Some ROM do checks in code to make sure they're running on an original cart.

>> No.2305790

>>2295437
>Some people might say that they are "emulating" a real cart though.
Some people might be retarded. A cart just houses the information in the same way a flashcart does which then runs on REAL HARDWARE.

>> No.2305823

>>2304429
did you even read the thread?

>> No.2305859
File: 1.27 MB, 683x1024, African Sights.png [View same] [iqdb] [saucenao] [google]
2305859

>>2305754

This is why a good emulator always dots all its "i's" and crosses all its "t's", as it were; so that the game _cannot_ tell that it's not running on original hardware. See Earthbound.

If the ROM can tell it's no longer in the cartridge, that's an emulation bug, not an inherent limitation.

>> No.2305876
File: 203 KB, 900x1238, bomberman_sprite___super_bomberman_2_by_recastanho-d5elitp.jpg [View same] [iqdb] [saucenao] [google]
2305876

A successful troll thread can last week on /vr/

>> No.2305887

>>2305876
The sooner we stop acting like pretending to be retarded = "trolling", the better

>> No.2305981

>>2305876
if you read the actual thread, OP was posing an argument someone else had asked him. You're the troll

>> No.2306340

>>2300249
>But with not as much accuracy as playing flash carts on the original hardware.

That heavily depends on what emulator you're using. bsnes is more accurate at emulating the original SNES model than the SNES Jr. is.

>> No.2306372

Emulation in the sense we're talking about is attempting to reproduce the behavior of everything in the hardware system (input data, computations, short-term memory, signal processing, signal output) after the input data, with the input data as a given.
Flash cartridges are a means of presenting to the genuine hardware a physical representation of a digital ROM, using rewritable hardware to arbitrarily use ROMs in a way that the physical hardware can comprehend. Not all cartridges are just raw data, some have coprocessors on them, and that's another part of the input system (from the perspective of the console).

>> No.2306973

>>2305859
That's being a bit harsh. Most emulators aren't designed to trick a game looking for an emulator because no games were designed to look for an emulator. That doesn't mean they're not good.

The EB copy protection only checks the cart not the system. It's very limited and easy to work around.

>> No.2307035

>insert videogame cd
>install, play the game

>insert USB drive with game installed
>now emulating the game

OK guys.

>> No.2307295

>>2307035
>Insert videogame cd into USB cd drive
>now tiny mind is blown

>> No.2307361

>>2306340
are you kidding? lol. the jr. (and the 1CHIP SNES in general) only exhibits minor graphical errors on some 1st gen titles.

it's nintendo hardware, not some china shit, come on dude

>> No.2307364

>>2306372
best answer so far.

how are the coprocessor functions emulated?

>> No.2307367

>>2307361
>le rustled 1CHIP owner

>> No.2307372

>>2307367
>>2306340
This parroting google shit is amusing.

>> No.2307386

>>2307367
>le rustled /vr/ shitposter on welfare justifying using emulators
>your face when I lhave literally every revision of the SNES, from the SVHC-CPU-01 to the 1CHIP

>> No.2307495

>>2307386
>>2307372

not even the other guy, just thought it was funny you guys got so up in arms over his comment. and you continue to . top kekkeroni

>> No.2307739
File: 1.17 MB, 1406x683, jeworder.png [View same] [iqdb] [saucenao] [google]
2307739

>>2295473
>The caveat is that these emulators wind up being inaccurate in several ways, whether it be framerate, sound, resolution, etc.
The way emulators are developed isn't the chief reason for inaccuracy. It takes time & effort, but "perfect" accuracy is possible for any system, and simpler systems like NES are 100% understood.

Lots of divergence from original hardware is seen as beneficial, like perspective-correct texture mapping on PSX emulators. There's no aesthetic benefit to affine mapping and it would require extra implementation effort, so its absence is understandable, even if accuracy is hampered.

Then there's the (I believe) information-theoretical impossibility of perfect emulation of analogue DACs and synthesizers and such. Any analogue signal processor can only be approximated, not replicated, by a digital one. Still, things can reach the point where most people couldn't tell the difference.

>> No.2308209

>>2307495
>top kekkeroni
Dank meme kid.

>> No.2308236

>>2307386
Your real hardware is worthless when we have nearly perfect emulators. Have fun "looking down" on using emulators to try to cope with your feelings of cognitive dissonance over wasting money on all that hardware.

>> No.2308242

The arguments against emulation of systems who are very accurately emulated are pretty much totally subjective and based in emotion, not logic.

>> No.2308251

>>2308236
The only console emulation that can be called near perfect is NES.

>> No.2308256

>>2308251
>doesn't know about bsnes
>doesn't know about Genesis Plus GX
>doesn't know about Mednafen PC-Engine and PSX emulators.

>> No.2308258

>>2308242
That's completely false. The most accurate emulators still have problems. Big one for id emulators aren't made for the real controllers but instead PC controllers.

>> No.2308260
File: 1.91 MB, 1200x900, Bryce.png [View same] [iqdb] [saucenao] [google]
2308260

>>2306973

I think you're inferring far more from my post than was ever originally intended. That being said, thank you for contributing to the quality of this thread unlike virtually half the assholes in here.

>> No.2308262

>>2308256
All those have compatibility problems
>doesn't know about Mednafen PC-Engine and PSX emulators.
Especially that piece of shit that can't even handle the PS1 controller properly.

>> No.2308280
File: 817 KB, 900x604, Canola Plants.png [View same] [iqdb] [saucenao] [google]
2308280

>>2308262

Now you're just trolling; it is _not_ the emulator's responsibility to handle voltage incompatibilities; that would be an adapter's job (should one exist for this particular scenario).

>> No.2308282

>>2308258
>>2308262

Oh please do point out the problems. All those except PSX emulator have perfect compatibility with no known issues. The PSX emulator is accurate for 99.9% of the library, with only a couple of obscure titles with issues due to being shittily coded and being extremely sensitive to CD timing.

FYI it is entirely possible to use the original controllers on PC with no extra lag.

>> No.2308287

>>2308280
>it is _not_ the emulator's responsibility to handle voltage incompatibilities; that would be an adapter's job (should one exist for this particular scenario).
If an emulator can't accurately handle the original controller then that emulator can not be called accurate.
The emulator touts about supporting PS1 controllers when in fact it doesn't. Unless you count having terrible rumble accuracy and an over voltage of over 66% to the board "supported".

>> No.2308289

>>2308258
>The most accurate emulators still have problems

They don't, as least not as far as you as a gamer should care. Given the same controller and display, you probably couldn't tell bsnes apart from a real SNES.

>> No.2308295

>>2308289
>>2308282
>FYI it is entirely possible to use the original controllers on PC with no extra lag.
It's possible if you enjoy destroying your controllers.

Timing issues and music quality differences still exist and will probably never be fixed.

>> No.2308296

>>2308262
bsnes has no compatibility problems in the latest version.

This has been proven with extensive testing.

>> No.2308305
File: 3.05 MB, 1600x1071, Cave Arches.png [View same] [iqdb] [saucenao] [google]
2308305

>>2308287

I repeat: an emulator is not responsible for hardware that is _physically_ incompatible with its host machine. Your problem is with whatever PC hardware manufacturers happen to be extant to your particular testing environment. All of this is assuming you're even being truthful; if >>2308282 is to be believed you're just 'sperging out at this point.

>> No.2308308

>>2308295
>Timing issues

Which are so small on cycle accurate emulators that you would have to also consider differences in timing between two different console units due to variances in the electronics. This is just pointless minutia.

>music quality differences

Supposed differences that only audiophiles could possibly notice, and nothing that would ever affect gameplay.

Neither of these are good arguments against emulation.

>> No.2308316
File: 27 KB, 600x600, smug.jpg [View same] [iqdb] [saucenao] [google]
2308316

>tfw burn roms to blank carts, print labels, manuals and boxes
>only argument collector fags have against this are entirely subjective and meaningless

I also sell them, I might've even sold one to you. Just think, the purity of your collection SOILED by an inferior copy, all the while you keep on in your ignorance, being pretentious as ever, not knowing the truth about yourself.

>> No.2308318

>>2307035
more like

>insert videogame cd
>install play the game

>insert copied videogame cd
>now emulating the game

Anything to justify the price of a collection I guess

>> No.2308321

>>2308308
>Which are so small on cycle accurate emulators that you would have to also consider differences in timing between two different console units due to variances in the electronics. This is just pointless minutia.
Nope. That's why TAS runs have to be done multiple times and the controller needs to go back and forth to check compatibility with the real hardware.

>Neither of these are good arguments against emulation.
I'm not against emulation. It is a fact it's no not "perfect" by any meaning.
>>2308305
>I repeat: an emulator is not responsible for hardware that is _physically_ incompatible with its host machine.
Last I checked PCs didn't come with controller ports for retro consoles.

Far as I know there's no adapter made for PS1 controllers that has the correct voltages. Same with some other controllers.

The emulation does not support the original controllers correctly. It's not accurate.

And the windows gpu drivers can cause lag.
>>2308296
Just because a game plays doesn't mean it's compatible. Still timing issues.

>> No.2308325
File: 84 KB, 1000x569, 3do_blaster_kit.jpg [View same] [iqdb] [saucenao] [google]
2308325

>>2308321
>Last I checked PCs didn't come with controller ports for retro consoles.
They exist. Either as special models or as addon cards.

>> No.2308327

If you don't collect physical media, use flashcarts, AND emulate you're a luser and have no right to be on this board. Everything has it's place.

>> No.2308328

>>2308325
>PCs didn't come with
I can by addon hardware all day anon.

>> No.2308336

>>2308328
But addon hardware still doesn't have magical voltage problems

>> No.2308337

>>2308321
Holy shit you are so dense. Read the post you're quoting: It's not the emulator's fault that computers don't have ports for Playstation controllers. It has no bearing on anyone's definition of emulation accuracy except yours, and your definition is malformed and doesn't help anyone.

Using TASes to represent the level of emulator accuracy just serves to indicate how accurate they are. If you have to go so far as to TAS something to come up with any tangible effects of emulation, it's probably pretty damn accurate.

>> No.2308342

>>2308321
>TAS

You're not helping your case there. Unless you're superhuman, of course.

>It is a fact it's no not "perfect" by any meaning.

Everyone knows "perfect" is unattainable. But "perfect" is not necessary since "almost perfect" is already excessive for the vast majority of players, and the real hardware is not really any kind of holy grail for playing games anyway, it's just the original way it was done.

>> No.2308345

>>2308336
It may. Not all addon hardware is made well.
>>2308337
If you couldn't use a NES controller with NES emulation people wouldn't call that emulator accurate would they?

>Using TASes to represent the level of emulator accuracy just serves to indicate how accurate they are. If you have to go so far as to TAS something to come up with any tangible effects of emulation, it's probably pretty damn accurate.
The fact that TAS is barely compatible with hardware means the emulation is good? It means it's barely passable as accurate.

>> No.2308348

>>2308321
what "timings" issue ?
Using TAS runs to define "perfection" is laughable.
If it sounds, displays and plays just like the original game then it can be considered as perfect "enough". Only autists who don't play games anymore would care of a tiny desync between a real console and an emulator running together simultaneously, especially when same desync happens after a while between two different real consoles.

Truth is people like you are endlessly unsatisfied because "perfection" does not exist (even with real haardware, you have CRT lovers, input lag freaks,...) or at least refers to things you cannot achieve yet, hence giving some stupid goal into some people's boring lives.

They like to consider themselves as "perfectionnists" or "purists" but they are just obsessed nerds who generally end up in depression.

>> No.2308350

>>2308345
>The fact that TAS is barely compatible with hardware means the emulation is good? It means it's barely passable as accurate.

Dude, you're being more of a zealot about accuracy than byuu was. TAS issues on real hardware are due to randomness that doesn't have to happen on emulators.

>> No.2308359
File: 33 KB, 400x400, 1392727212797.jpg [View same] [iqdb] [saucenao] [google]
2308359

>>2308350
>>2308348
Bring up a problem with emulators and the fanboys sure do get upset.

Well you guys have fun arguing over how accurate an emulator should be. They can't be too accurate otherwise that's just autistic. You need a hipster level of accuracy. Something not perfect but still playable. Ya...

>> No.2308363

>>2308345
>The fact that TAS is barely compatible with hardware means the emulation is good? It means it's barely passable as accurate.

If TAS recording was possible on real hardware, it would likely not be fully compatible on another console and desyncs as well after some time.

Also, unless you run TAS on real hardware with the exact same input means as with an emulator, it's hardly a valid way to define what is accurate and what is not.

>> No.2308367

>>2308328
What is a PC if not the sum of its parts?
It's no longer a single of IBM products.

>> No.2308372

>>2308359

Just like real hardware fags don't like getting told that emulators are just as good or better and that most of their reasoning is due to placebos and emotions.

>> No.2308375

>>2308372
Timing issues are placebo and emotions?

>> No.2308376

>>2308287
>an over voltage of over 66% to the board "supported"

what is this shit again? Is it the new cool thing to brag about among vg "purists" ? I have been using my old DS through an USB adapter for years and never had any issues.

>> No.2308378

>>2308375
Yes, especially when it has no actual effect on the games themselves, and especially when different instances of hardware can have differences.

>> No.2308380

>>2308375
When they can only be noticed by computer-based replayers or frame-by-frame camera recorders, obviously.

>> No.2308381

>>2305876
But any thread can last a week on /vr/

>> No.2308386

>>2308380
>>2308378
That would be called not accurate.

>> No.2308392

>>2308386

You have a definition of "accurate" that is far stricter than anyone else on the planet, then. Even byuu admits accurate emulation is not perfect emulation.

>> No.2308401

>>2308392
If the emulation doesn't react the same way as a console to a nuclear explosion (B61, airburst) going off right next to it then it can't be called accurate.

>> No.2308428 [DELETED] 
File: 892 KB, 1010x674, SON OF A BITCH MUST PAY!.png [View same] [iqdb] [saucenao] [google]
2308428

>>2308401

Never have I loved a devil's advocate more in a conversation. XD

>> No.2308439

>>2308392
Why do you keep mentioning Byuu? The guy's a contradicting idiot. He's deleted and edited many of his posts because of his contradictions.

>> No.2308445

>>2308439

While I do agree the guy definitely has some personality problems, I'm willing to give him a bit of a break on those because they're so outweighed by his usefulness.

That being said, the last few years have not been kind to his sanity and I hear things are getting worse for him, not better.

>> No.2308451

>>2308445
You got people like Fudoh and RetroRGB that have nice things to say about the 1chip bullshit for example. People that deal with real hardware.

>> No.2308470 [DELETED] 

>>2308428
>XD

>> No.2308476 [DELETED] 
File: 1.48 MB, 1024x768, Cold And Clear.png [View same] [iqdb] [saucenao] [google]
2308476

>>2308470

Ah, I love triggering auts in the morning. :)

>> No.2308543 [DELETED] 

>>2308476
Not him but you're not in a chatroom, putting smiley faces in every post actually violates a 4chan rule.

This is an imageboard, use images for that kind of stuff, like everyone else does.

>> No.2308563

>>2308439

Whatever you say about Byuu's personality, or his behavior, you can't discount his skills.

Dude's a loon, but he's given the SNES emulation/romhacking community invaluable contributions.

>> No.2308568 [DELETED] 
File: 868 KB, 909x716, Devil's Mound.png [View same] [iqdb] [saucenao] [google]
2308568

>>2308543

I haven't used them "in every post" you fucking mong.

(;D)

>> No.2308589

>>2295415
Same reason it isn't emulation when you burn an iso onto a disk and pop it into a dreamcast; it's playing on the genuine hardware, therefore, it's simply pirating the game.

>> No.2308593

What actually is a 'flashcart'? Where do you get one?

>> No.2308595

>>2308593
>What actually is a 'flashcart'?

It's a kind of adapter that allows you to play downloaded roms on actual hardware.

>> No.2308598
File: 181 KB, 1439x1078, 1400418750691.jpg [View same] [iqdb] [saucenao] [google]
2308598

>>2308595
Oh, neat. That sounds a little better than paying these scalper-ass prices I find everywhere, for the few games I want.

>> No.2308618
File: 75 KB, 1061x1300, .-).jpg [View same] [iqdb] [saucenao] [google]
2308618

>>2308568

>> No.2308652

>>2307386
>I lhave literally every revision of the SNES, from the SVHC-CPU-01 to the 1CHIP. IN MY MIND!

>> No.2308664

>>2308316
I'm telling mom you're using her printer to make labels for your imaginary carts

>> No.2308957

>>2308316
10/10 good goy

>> No.2309042

>>2308236
it cost me $20 total, junk consoles in japan cost literally $3 USD and usually work fine!

>>2307495
the 4chan treat

>>2308451
1chip does give better image quality at the expense of minor glitching with some older software titles.

>>2308652
so how much btc do you drop in my wallet after I take a nice photograph of them while flipping you the bird? name a price and i'll make it happen, with timestamp

>> No.2309052

>>2308236
it subjectively feels better to play a flashcart on original hardware than an emulator. not sure 100% why

>> No.2309087

>>2309052
>subjectively feels better to play a flashcart on original hardware than an emulator.
>subjectively feels better
>subjectively

Introducing: the new Objectively

This is 4chan.

>> No.2309340

>>2295437
Imagine you wrote a book.

Now imagine someone takes your book and rewrites it, word by word. This is emulation. It's prone to errors.

Now imagine someone takes your book and rips out all the pages, one by one. They get a new cover and put the pages together again. This is a flashcard.

>> No.2309354

>>2295415
An emulator simulates the hardware of the console, not the software. The rom you play on an emulator is literally the same file that the console would read.

>> No.2309537

>>2308209
thanks man i had to go thru 6 years of meme wizard school to cast that one

>> No.2309557

>>2308316
i think you are full of shit anon, because it would cost more to produce a repro homegrown than you would make selling it back.


>do you own a cutting machine?
>where do you get the sorces for carts that have no scans for labels or manuals?
>how are you printing boxes? That would set you back a couple grand.

To make a 1:1 copy on your own and not in chink land is infeasible.

>> No.2309602

>>2308327
Hear, hear!

>> No.2309668

>>2308392
Not him, but it's a digital, constant-clock system. If you can detect a difference in behavior, it isn't 100% accurate. There's a reason why any organization of speedrunners that isn't retarded only counts runs on original hardware, regardless of how accurate modern emulators and how convenient USB controller adapters are. I have one myself, and I can run Super C and Mega Man 2 semi-competitively, but even if I worked at it and became really competitive, I would never lobby any org to accept my runs performed on an emulator (by Byuu or anyone else); that would be stupid.

Why? Because software emulation of hardware is never going to reproduce the output of the hardware to 100% accuracy, with timing being the most insurmountable challenge. Even if the emulator itself were as close to perfect as you can come, a multitasking operating system (particularly windblows) running on an x86 family processor is never going to match the timing of the various ancient components that go into a retro console, including DSPs, PPUs, and CPUs all potentially running at different clock speeds. Is it good enough to reproduce the general experience of the game beyond any differences that the average human can discern? Yes. Is it 100% accurate and suitable for regulated and/or validated competition? Fuck no. "Pretty god-damned close" still involves a measure of error that is inauthentic to the real hardware components that are on those boards, and that's as close as you can get with a modern multitasking-hosted emulator running on CPUs, GPUs, RAM, etc. that are advanced alien species compared to the chips inside anything older than a 6th gen console. You're not going to be able to underclock them to perform like their ancestors without building a new rig, at which point you'll just end up cloning the older consoles, not emulating them.

>> No.2309683

>>2309668
Who says you have to use Windows? Why would x86 be worse than PPC or ARM?

>> No.2309841

>>2309668

That's not correct.

There are two different things to consider when we're talking about the timings in an emulator: the "internal" timings (that is, the emulated timings of the original hardware) and then the "wallclock" timings, how fast the emulator appears to be running.

The *internal* timings (i.e. the original CPU executed an addition in 4 cycles while the GPU can render a line in 300 cycles etc...) should *never* be influenced by the host scheduler or anything. Or your emulator is seriously broken. In the emulator you always advance the state of all your peripherals synchronously. From the point of view of the game being emulated everything advances always at the same speed since all the timers and all the peripherals always advance synchronously. You can't have the CPU suddenly go faster than the GPU and mess everything up.

Many emulators don't emulate all the nitty gritty details of the original hardware and take some freedom with the original timings. They're going to say that, e.g. "on average a RAM access takes 8 cycles" or "the DMA copies 10 words in 12 cycles" even though it's not necessarily correct. They do that either because they don't know how to emulate the real timings (because they depend on too many parameters like RAM refresh rate and bus arbitration and whatnot) or it would require too much emulation time when the average value is "good enough" for most cases. That's probably not good enough for speed running though.

It doesn't mean that it's impossible to make an emulator cycle accurate, just that few people actually bother doing it. Take a good emulator for simple hardware like gambatte for the GB and I'm fairly confident that you won't be able to find a single timing difference with the real hardware over an entire speed run of a game. Not even a single cycle.

>> No.2309846

>>2309668
Even 2 different console won't have 100% exact same timings so your TAS runs are worthless to measure accuracy. Also they require custom external hardware to run on real consoles so they are very subjective to the timing precision of said hardware.


Next, your analogy with x86 processors not having the same timings as old processors only shows how ignorant you are about how emulation works and explain a lot why you have psychological blocking with emulators.

The timings of the CPU which is emulating is not a problem. It's running way faster anyway, because it needs that extra time to emulate not only that old CPU but all the other hardware parts which made the console.

Those old console timings CAN be emulated... as long as someone figure them out. Most emulators assume official CPU timings and often does not emulate bus refresh cycles or wait-states when two emulated devices are accessing the same bus, because that is often undocumented and because the difference in the end is so minimal that it has no noticable effect on games.

The difference only appears in stupid benchmark test roms or useless TAS run comparisons that real hardware fanboys use to justify their hate for emulation and feel "special"

>> No.2309854

>>2309841

Continued:

Now there's the "wall clock" time. Even if the internal state is 100% coherent and accurate it's still possible that the host OS will drift and have the emulator run slower or faster than the real console would (but *all* the emulated state would run slower or faster, the run would still be fully deterministic and coherent). That being said if your host hardware is good enough there's simply no reason for that to be significant.

In general games run at 30 or 60fps, it's doubtful that anything under a few milliseconds is really significant. It's easy to reach under a millisecond latency with any decent operating system. And you're still vastly under a single frame of latency.

And if that really matters to you then here comes the shocking revelation: no two consoles will have exactly the same timings anyway. No two oscillators will give out exactly the same frequency. Some systems use different clock sources for different peripherals which means that two peripherals won't be synchronous on real hardware while they will be in a good emulator. In this case one might even argue that an emulator is actually better for competition since it can garantee 100% reproducible runs while the original hardware itself might not (maybe one peripheral will have to skip a cycle in the resynchronization interface in certain conditions). It's probably never significant though.

So the reality is: emulators are *generally* not good enough for speedruns because most of them are not accurate enough. It doesn't mean it's impossible and I'm sure there are a few emulators out there (gambatte, bsnes come to mind) that *might* be good enough.

>> No.2310583

>>2309854
I hope you feel better now that you got all that off your chest.

>> No.2310790

>>2302202
wow
much edge
so hostile
I'm implying you should work on the source code for the SD2SNES yourself if you're so unhappy with the current state you goddamn fucking moron

>> No.2311747

>>2308401
underrated post

>>2309052
This is the crux of it- expectation colors perception. Using the original hardware can ''feel'' very different even if you rationally know the real differences are well below the threshold of perception. So original hardware will always be important.

>> No.2311976

>>2309841
>>2309854
I never said anything about TAS runs. Yes, two consoles will vary in timing, but when you complete a run, you can legitimately say that your run took EXACTLY that amount of time on at least one REAL set of hardware. Like how race car drivers all have to use slightly different cares even though they're 99.9% similar. On a real console run, each chip and DSP did its work in parallel as separate pieces of hardware, rather than a single CPU emulating everything serially and then adding it all together. On an emulator, you preserve the order of operations and the PROPORTION of time required for each low-level action to complete at a cycle-level of granularity, but you do not preserve the actual timing of each chip. Emulator coders don't necessarily know the order of independent events happening on the different chips on the board WITHIN a cycle, they just know how many cycles this or that event takes. A transistor-accurate Pong emulator runs at less than 20fps on modern PCs, and the accuracy build of Higan can suffer frame delays on an i7. Emulating a grab-bag of DSPs, memory controllers, DACs, etc. and a CPU is an exhaustive task if you plan to be faithful to the individual chips that make up the board. They're all running in parallel, and they're free to do so at their own pace. The 2-4GHz CPUs of today's desktop computers can keep up with Gen 4 consoles as long as you treat all those pesky little chips as black boxes operating under a strict contract of "cycles-per-op" idealism, but that isn't true to real hardware soldered together on a real PCB. bsnes/higan is the only playable emulator that takes into account the different timings of the chips involved, and it's the only SNES emulator with full compatibility, including raster effects and that Speedy Gonzalez game. If an emulator plays different than real hardware on ANY game, it is not "accurate" reproduction of behavior, just generalized emulation.

>> No.2312404

>>2311976
>If an emulator plays different than real hardware on ANY game, it is not "accurate" reproduction of behavior, just generalized emulation.

Except that in most cases, cycle-accuracy is not required for accurate reproduction because games are generally made with some timing tolerance. Even timing sensitive games could be fairly emulated with timing approximations, given you allow mid-frame and mid-line changes in your emulator.


The rest of your post is a mixup between weird assumptions and generalizations which do not seem to make any points besides stating what everybody already know.

Just because emulated chips do no run in parallel at exact same speed does not mean that you can not get exact reproduction of game speed, audio and visual. All that matters is that the proper number of instructions are executed by frames and that access to graphics/sound chips are done at the right time regarding said chip progression in frame. What happens internally between those syncing points and how fast it is emulated is not important, what matters is relative timings.

>> No.2312465

>>2310790
>I'm implying you should work on the source code for the SD2SNES yourself if you're so unhappy with the current state you goddamn fucking moron
I shouldn't have to. And who's being hostile now?

>> No.2312484

>>2309087

the word was used in the literal sense tho

>> No.2312495

>>2310790
>implying
how new are you?

>> No.2313253

>autists autisming autists autisming autists

>> No.2313256

>>2313253
best post 2015

>> No.2313728

>>2308345
What controller you can and cannot use matters exactly jack shit for accuracy.

>> No.2313780

This thread wasn't too exciting at first but got progressively more impressive the longer it went on.

>> No.2315885

>>2312404
>Except that in most cases, cycle-accuracy is not required for accurate reproduction because games are generally made with some timing tolerance.
That is complete horseshit. Maybe what you meant to say is that many times a small difference in timing will not make a difference in the output. That does not discount the times when it does, which might mean a missed collision or a single frame delay; or it could freeze the game, fail an essential trigger, or otherwise noticeably change the gameplay. Developers don't code magical "timing tolerance" into the game. They code something that's supposed to work and then they test it on real hardware of which they know just as much as the console and chip designers tell them: i.e. just enough to get something working. They don't know when they're straddling an edge case within a complex system of proprietary chips, nor could they. A game company isn't an enclave of EE PhDs. I take it you have zero experience developing software for a target system of closely guarded design you aren't privy to. You hit an undocumented bug, you find a workaround, you move on. Advances in console emulation generally depend on schematics anonymously donated by sympathetic employees. The "timing approximations" used before this data is available are crude guesswork that cannot produce full compatibility and are a miles upon miles away from an "accurate representation" of a console's behavior within a library of hundreds or thousands of games and millions upon billions of unique hardware states. Emulators that don't accurately simulate coprocessor timing use different patches for all the most popular games and deviate hugely from real hardware output for the majority of games they don't have workarounds for. The NES isn't that complicated compared to later systems, and yet:

http://wiki.nesdev.com/w/index.php/Tricky-to-emulate_games

>> No.2315958

>>2310790
your words said otherwise, you illiterate cock sucking piece of shit

>> No.2315985

>>2315885
keywords are "most cases" and "generally", off course timing sensitive games exist but it's not the majority.

Again, tricky to emulate games can generally be emulated without game-specific patches and without "cycle accuracy", it's just that most emulators are limited to scanline granularity and does not handle midline changes which those games do.

So you need to support that to get timing sensitive games working but you don't need the timings to be cycle exact necessarely, because, again, commercial games have some tolerance with events timings, not because they "coded" it (never implied that) but because they tend to follow official software development guidelines, which by nature try to avoid doing things that rely on cycle-precise timings but rather sync with event related timings (like interrupts,status flags triggering, etc) to ensure it will work on every console hardware out there, and not work "by luck".

People doing demos or test programs nowadays are not representative to how commercial games were developped back then.

>> No.2315990

>>2295449

There are TONS of romhacks that will not run on real hardware, some are even designed specifically to run on certain emulators.

>> No.2316118 [DELETED] 

TL;DR: The Thread

>> No.2316372

>>2315985
> off course timing sensitive games exist but it's not the majority.
Virtually every game produces output that is "timing sensitive", as the output of the complex computation process is liable to change in tandem with changes in timing of the coprocessors. The nature of the games themselves is such that the user can easily overlook a frame-delayed event here, a color error there, or a race case resolving differently than it does on a real system. Other times, the game breaks entirely, but this is no less an "accurate reproduction" of the system's behavior than when a collision check that should occur ever other frame instead occurs every frame, even if the player doesn't notice the difference. That's just the nature of games themselves that helps to cover up these inaccuracies.

>but rather sync with event related timings (like interrupts,status flags triggering, etc)
Event detection occurs within a cycle. Change the timing, and the event context changes, potentially breaking gameplay.

>People doing demos or test programs nowadays are not representative to how commercial games were developped back then.
I never said anything about demos or test programs. That's how software gets written on someone else's hardware. Care to offer some evidence or even just specific examples of this bullshit you're pulling out of your ass about how games were developed back then?

>> No.2316740
File: 114 KB, 904x421, 1.jpg [View same] [iqdb] [saucenao] [google]
2316740

Here's everything you need to know about their logic.

>> No.2316748
File: 4 KB, 240x76, 657568xks.jpg [View same] [iqdb] [saucenao] [google]
2316748

>>2316740
No milk=emulating?

>> No.2316778

>>2316748
is that even milk? It looks like someone put their corn flakes in a bowl of yogurt.

>> No.2317161

>>2316740

You got that backwards. Emulators render in higher resolution than the real console ever would. You don't need a fucking external upscaler for emulators and 3D renders much better too.

Face it fags - emulators are superior when they are compatible and don't exhibit extra glitching.

>> No.2317256

>>2316778
Stock footage milk is usually glue.

>> No.2319571

>>2317161

>>2317256

>> No.2320062

>>2316372
>The nature of the games themselves is such that the user can easily overlook a frame-delayed event here, a color error there, or a race case resolving differently than it does on a real system.

The point is that if this is not noticeable, hearable and produce no display differences then it can be accepted as an accurate reproduction of the game.

You are overestimating the benefit of cycle accuracy. Even claimed "cycle-accurate" emulators are not 100% perfect either and make some compromises with timings to "get things right".

>Event detection occurs within a cycle. Change the timing, and the event context changes, potentially breaking gameplay.

Again, "potentially" but in reality it's often not the case.You are giving too much importance to what "potentially" could break because your mind can not accept things could still work "fine" despite not being "perfectly" emulated.

Let me explain: for events like "start of line" or "end of active display", etc... it does not matter if the timings are not 100% exact, what matters is that the emulator reports and processes these events correctly relatively to each other.

Similarly, if a game is polling a flag, it will makes no difference if the flag is positionned one CPU cycle after it should have unless that event has some effect with another event in the rest of emulated hardware. If all events are correctly handled relatively to each other, it will be transparent to the game.

Even with interrupts, it does not matter if the timing is off by one or two cycles because games are (generally) not programmed to rely on interrupts occuring on a specific cycle but would rather do things that don't mind being interrupted while waiting for interrupts.

Off course I'm not talking about timings being off by hundred of cycles or frames, I'm talking about timings not being 100% exact to real hardware.

>> No.2320069

>>2316372
> Care to offer some evidence or even just specific examples of this bullshit you're pulling out of your ass about how games were developed back then?

Easy. Most games were developped following official software guidelines. If they didn't follow these guidelines, they would be rejected by the software licenser..

You can read those guidelines now as some of them were leaked. They were giving recommandation on how to use the console hardware and how to not abuse it.

You can also analyse games and disassemble it like I did and see how they are programmed.

Truth is most games do not rely on cycle granularity, they do not "count" cycles to know when to access hardware parts and they are mostly waiting for events to occur to trigger some specific task.

For example, they do not try to access sound chip before it's ready and they do not write to PPU RAM while it is rendering active pixels, becaus ethey know the result could be unpredictable, depending on the timings where the writes occur.

If some event is delayed or advanced by a few cycles, it won't "break" the game unless it's very badly programmed and it won't make it sound or display differently unless the timing of events is way off compared to real hardware or the hardware is badly emulated, which is not the case anymore with modern emulators.

>> No.2320078

>>2320069
>Most games were developed following official software guidelines. If they didn't follow these guidelines, they would be rejected by the software licenser..
What about those tons of systems without a software licenser?

>> No.2322521

>>2295421
>>2295423
right, but isn't a flash cart emulating a real cartridge? wouldn't that still be emulation because it's pretending to be a real cart?

>> No.2324071

>>2322521
Technically the SD2SNES could be considered emulation, since it uses programing to EMULATE hardware like the SuperFX chip. But that's about it.

>> No.2324602

>>2316740
>Playing on original hardware is like eating hipster cereal
>I was sick the day of the "all dogs are black" logic lesson in 3rd grade

>> No.2324718

>>2320069
>Most games ... official software guidelines. If they didn't follow ... rejected by the software licenser..
[Citation needed] The Nintendo Seal of Approval dealt with the quality of the overall game experience and the general absence of game-breaking bugs or obvious, common bugs. How that was achieved wasn't their concern. There is a reason why games become much more impressive later in a system's lifecycle, and it has fuck all to do with nonexistent code audits.

>>2320062
>too much importance to what "potentially" could break because ... still work "fine" despite not being "perfectly" emulated.
You never provided me that list of emulators with 100% compatibility and rendering accuracy that aren't at least cycle accurate. If your claim were true, N64 emulation would be stellar. Is it?

>Let me explain: for events like "start of line" or "end of active display", etc... it does not matter if the timings are not 100% exact
In >99% of cases it doesn't, but the <1% will still be obvious to the player without all the patches applied to popular games, whether they were 1st or 3rd party. Games were written for hardware, not emulators, so these hacks were necessary to make general purposes emulators, rather than single-game emulators. Speedrunners regularly discover useful new bugs that don't work on these hardware-abstracted emulators. EMULATING the real thing and accurate REPRODUCTION of program execution are completely different things. You can ignore this as an end user, but generalized "timing tolerance" is pure journalistic fiction used to gloss over the details of emulation.

>> No.2325452 [DELETED] 

>>2324718
>You never provided me that list of emulators with 100% compatibility and rendering accuracy that aren't at least cycle accurate.


BSNES accuracy is not cycle-perfect either as its PPU emulation fails with some demo programs or homebrews that are fine on hardware but has perfect compatibility with commercial games and no known rendering issue either.

GenPlus GX is not cycle accurate but has perfect compatibility and no rendering issues with all games. Also handles some tricky demos that other emus fail with (Overdrive demo).

>Speedrunners regularly discover useful new bugs that don't work on these hardware-abstracted emulators..

Have you examples using the above emulators? Just because people use old and inaccurate emulators for TAS does not mean accurate emulation can not be done.

Also, once again, using TAS on real hardware to judge accuracy of emulators is a little bit misleading: real hardware TAS need an external device to input the recorded TAS to the console so the timings are likely going to be slightly different from an emulator where inputs are synchronized to emulation while the external device is not synchronized to the console reading input ports for example.

>"timing tolerance" is pure journalistic fiction used to gloss over the details of emulation.

I know how emulators work and how they are written. Do you? I have also disassembled and analyzed many games to help fixing emulator bugs and I can tell you that only a few of them do nasty things and this is often due to bugs in the original game that appear to work "by luck" on real hardware.

Now, just because a few exist does not mean that ALL games are that much timing-sensitive.
The majority of them have no emulation issues and work out of the box without any glitches even when the timings are way off.

>> No.2325469

>>2324718
>You never provided me that list of emulators with 100% compatibility and rendering accuracy that aren't at least cycle accurate.


BSNES accuracy is not cycle-perfect as its PPU emulation fails with some demo programs or homebrews that are fine on hardware but has perfect compatibility with commercial games and no known rendering issue .

GenPlus GX is not cycle accurate but has perfect compatibility and no rendering issues either with any games. Also handles some tricky demos that other emus fail with (Overdrive demo).

>Speedrunners regularly discover useful new bugs that don't work on these hardware-abstracted emulators..

Have you examples using the above emulators? Just because people use old and inaccurate emulators for TAS does not mean accurate emulation can not be done.

Also, once again, using TAS on real hardware to judge accuracy of emulators is a little bit misleading: real hardware TAS need an external device to input the recorded TAS to the console so the timings are likely going to be slightly different from an emulator where inputs are synchronized to emulation while the external device is not synchronized to the console reading input ports for example.

>"timing tolerance" is pure journalistic fiction used to gloss over the details of emulation.

I know how emulators work and how they are written. Do you? I have also disassembled and analyzed many games to help fixing emulator bugs and I can tell you that only a few of them do nasty things and this is often due to bugs in the original game that appear to work "by luck" on real hardware.

Now, just because a few exist does not mean that ALL games are that much timing-sensitive.
The majority of them have no emulation issues and work out of the box without any glitches even when the timings are way off.

>> No.2325545

>>2324071
>since it uses programing to EMULATE hardware like the SuperFX chip

Now if only it actually emulated Super FX I'd be a happy camper.

>> No.2325639

>>2325469
Isn't Exodus the cycle accurate Genesis/MD emulator? GenPlus GX is popular for other reasons.

>> No.2326158

>>2325639
>Isn't Exodus the cycle accurate Genesis/MD emulator?

Yes but it is still work-in-progress and currently has some compatibility issues.

>> No.2326196

>>2308316

I bought my games in the 90s from actual stores. My "collection" is the games still lying in my closet since then.

>> No.2326228

>>2305823
Did you? Op is retarded.