Ontwikkelaar krijgt Windows 95 werkend op Nintendo 3DS

Het is iemand gelukt om Windows 95 te installeren en werkend te krijgen op een Nintendo 3DS. Omdat de benodigde code online is gezet, is het voor anderen ook mogelijk om het besturingssysteem op de handheld te zetten.

In een video is te zien hoe Windows 95 opstart op de handheld-gamingconsole. Deze is online gezet door een gebruiker met het pseudoniem shutterbug2000. In een forumthread op GBA Temp legt hij uit wat hij gedaan heeft om het besturingssysteem werkend te krijgen; omdat hij de benodigde code op GitHub heeft gezet is het voor anderen ook mogelijk om het OS op de Nintendo 3DS te installeren.

Verscheidene gebruikers hebben bevestigd dat het met de geüploade code mogelijk is om Windows 95 te laten functioneren op de Nintendo 3DS. Wel kampt de software met prestatieproblemen, zoals lage framerates. Ook is het nog niet mogelijk om het touchscreen te gebruiken, waardoor de bediening moeizaam is.

Waarschijnlijk wordt de implementatie van Windows 95 op de Nintendo 3DS in de toekomst nog verbeterd. Op het forum van GBA Temp spreken ontwikkelaars over het schrijven van emulators om pc-games op de handheld te spelen. Het moet nog blijken in hoeverre deze plannen levensvatbaar zijn.

Reacties (106)

[Squ1zZy]

Voor diegene die de werkende code wilt downloaden. Het staat op zijn dropbox:

https://www.dropbox.com/s...lf/retroarch_3ds.zip?dl=1

Hoe het uit te voeren legt Kyouken in het kort uit op de volgende pagina:
http://gbatemp.net/threads/windows-95-on-n3ds.407539/page-11

Ook heeft iemand inmiddels Windows 3.1 en 98 draaien
http://gbatemp.net/threads/windows-95-on-n3ds.407539/page-22

Edit: Link naar Youtube voor het Windows 3.1 en Windows 98 filmpje:
https://www.youtube.com/watch?v=RSoGx6h7P5w

[Reactie gewijzigd door Squ1zZy op 23 juli 2024 02:34]

[seapip]

Die dropbox link gaat dus binnen de kortste keren plat...
Hier maar alvast een mirror: http://www10.zippyshare.com/v/F8IeOYFu/file.html

[TheRealProcyon]

Klopt ik ben op dat forum procyon. Alleen werkt het, momenteel, alleen op de New Nintendo 3DS. Team fail probeert het werkend te krijgen op de oude 3DS.

[aadje93]

*wel kampt de software met prestatieproblemen* ja, een 3DS is nou niet echt een pentium 3 denk ik zo.... (3DS = dual core 266mhz)

[Benjamin-]

Pentium 3 kwam dan ook pas uit in 1999... zelfs de Pentium 2 was nog niet eens uit in 95.
Windows 95 was gericht op 486 hardware, en als ik me niet vergis was de snelste 486 processor iets van een DX4 120mhz, dus dan is de 3DS veel sneller.

Verder grappig dat dit kan, maar heb er zelf geen interesse in. Dit soort projecten draaien echt om het tweaken, om de limieten en mogelijkheden op te zoeken.

[The Zep Man]

Windows 95 was gericht op 486 hardware, en als ik me niet vergis was de snelste 486 processor iets van een DX4 120mhz, dus dan is de 3DS veel sneller.

De snelste 486 kwam van AMD en draaide op 150 MHz.

Waar je geen rekening mee houdt is dat een ARM CPU cycle niet gelijk is aan dat van een x86 CPU. Ja, in klok is die 486 veel trager, maar per klok kon hij veelal meer berekenen dan een ARM CPU door de uitgebreidere instructieset. Stel dat je voor een rekensom geen 12 cycles nodig hebt, maar het met slechts een enkele cycle kan doen.

Ook wordt gebruik gemaakt van emulatie, waar altijd wat overhead in zit.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 02:34]

[hansg]

De x86 per klok meer berekenen dan een arm? Als je typische x86 code bekijkt dan ziet het er als volgt uit: mov-mov-doe iets-mov: eerst twee argumenten in de juiste registers laden, een operatie, en dan weer een mov om het resultaat op te slaan. Arm heeft veel meer registers en kan tussenresultaten veel eenvoudiger in register houden. Arm code is daarom vaak veel compacter, met enkel instructies die iets doen ipv. data rond te schuiven.

In gemiddelde x86 code is er bovendien een jump op ongeveer elke 4.7 instructies. Arm kan _elke_ instructie conditioneel maken, waardoor een if/then/else operatie met weinig (of geen) instructies in elke branch compleet zonder jumps kan worden uitgevoerd. Ook dat levert nogal wat dichtere code op, en het komt branch prediction ook ten goede - al denk ik niet dat dat toen al veel uitmaakte.

De 486 was bovendien nog niet zo geavanceerd als moderne x86 processors, en kon maximaal 1 instructie per cycle retiren. Het is dus, kortom, zeker niet waar dat een 486 meer per klok kon berekenen dan een beetje arm CPU. Integendeel zou ik zeggen.

[Benjamin-]

Wij zijn thuis nooit hoger uitgekomen dan 120, ik zie dat 133mhz de hoogste retail was, dan hebben we dus niet veel gemist.

Ik weet hoe CPU's werken, maar dat was ook als reactie op aadje.

Wat betreft die cycles, het is nog maar de vraag of spellen in die tijd wel echt effectief de CPU gebruikte. Ik heb echt nul verstand van hoe dat destijds ging, maar het zou me niet verbazen als spellen heel beperkt gebruik maakte van de mogelijkheden van de CPU.

Maar inderdaad, het verlies zit hem in de emulatie, en afhankelijk van hoe effectief ze dit krijgen, zal dit bepalen of het uberhaupt redelijk te draaien is. En dan heb je wederom de vraag, maakt het uit of het goed zal gaan draaien?

[Exorcist]

Spellen leunden met name op de CPU, omdat GPU's nauwelijks waren ontwikkeld met als doel het beter laten presteren van spellen. Dat brak pas echt aan rond de Riva TNT en 3DFX kaarten.

Weet nog dat ik destijds van een 512KB (!) ISA videokaart naar een 1 MB PCI videokaart ging, en Duke Nukem 3D ineens liep zonder haperingen. Good times. Heb zelfs nog mijn eerste Voodoo Rush kaart liggen als ik me niet vergis. Werd totaal niet gekoeld, zelfs niet passief, en werd bloed-en bloedheet

[Benjamin-]

Dat kan ik me allemaal al te goed herinneren.
CPU was inderdaad alles, de sprong met mijn Voodoo 2 kaart kan ik me ook nog goed herinneren.

Maargoed omdat spellen vrijwel alleen de CPU gebruikte, betekent natuurlijk niet dat ze de CPU effectief gebruikte.
Of dit zo ook was, dat weet ik dus niet.

[Fiander]

wat bedoel je met "effectief gebruiken"?
een 486 had GEEN sse, mmx of 3dnow instructies. er waren alleen x86 en soms x87 instructies mogelijk.

ontwikkelaars waren toen nog echte bit-beesten, welke juist echt alles uit een cpu wisten te knijpen. in tegenstelling tot nu waar het goedkoper is om er gewoon meer hardware tegen een probleem aan te gooien.

Ik weet me nog een interview met een game ontwikkelaar te herinneren.
deze ontwikkelaar was bezig met een 3d engine, en zat met die engine op 11 klokpulsen per pixel, hij sprak daarna een andere ontwikkelaar, en die kon het in 9 klokpulsen. Omdat hij toen wist dat het in 9 kon, is hij verder gaan zoeken, en kwam uiteindelijk op 7,5 klokpulsen uit.
( ipv per pixel rekende hij toen twee tegelijk uit ( pre sse tijdperk !!!) en kwam met twee pixels op 15 klokpulsen.

geloof me, juist toen gebruikten ze de cpu erg effectief en efficient.

[Ayporos]

ondersteunt windows 95 uberhaupt multi-core CPU's?...

[Fiander]

nee, maar wellicht de emulator wel? wanneer win95 een stuk hardware aanspreekt, kan dat dankzei de emulator best door de ander core afgehandeld worden.

[hiostu]

Dat kan dan wel voor hele rare dingen gaan zorgen. Als een programmeur geen rekening heeft gehouden met multithreading dan kun je niet zo maar de werklast gaan verdelen.over verschillende CPUs. Hooguit twee geheel verschillende processen op twee verschillende CPUs draaien, maar niet een enkele applicatie.

[Fiander]

Hoezo dat?
vanuit het oogpunt van een emulator kan best een cpu door één core afgehandeld worden, en een video kaart/geluidskaart door een andere core. dit zijn ook bij win95 chips.

Het gaat er om dat de emulator baat bij meerdere cores kan hebben terwijl het slachtoffer ( win95 dit keer ) daar helemaal geen ondersteuning voor hoeft te hebben.

[hiostu]

meeste software voor thuisgebruik uit die tijd ondersteunde niet meer dan 1 CPU met enige uitzonderingen (bv Quake 3). In die tijd had bijna geen enkele thuis pc multi cpu's. Meeste software was dus ook niet geschreven voor multithreading en dan kun je ook niets over meerdere cores gaan verdelen.

[Fiander]

zucht....
Is de emulator in die tijd geschreven?
kan de emulator wanneer het guest OS een geëmuleerde videokaart probeert te benaderen hiervoor een andere core van de host gebruiken?

dus maakt het uit dat win95 of wat dan ook geen Multi core heeft? de emulator kan de extra cores nog steeds gebruiken.

Op geen enkel moment heb ik beweerd dat een standaard software pakket uit die tijd meerdere cores zou kunnen gebruiken. het enige wat ik heb geschreven is dat een emulator additionele ( virtuele ) hardware door een andere core zou kunnen laten uitvoeren. Dat houd helemaal niet in dat de guest software dan opeens meerdere cores zou moeten ondersteunen.

[un1ty]

Windows 95 ondersteund native inderdaad geen dual core/CPU.

Echter met enkele (community) updates/patches is dit wel toe te voegen.
Daarnaast kan Windows 95 niet overweg met CPU's sneller dan 1GHz.
Ook dit is op te lossen met dezelfde patches.

Het voornaamste probleem zat hem in de modem drivers.

Ik vraag me af welke 95 versie zij gebruiken...
Ik heb ergens nog een kopie staan die in virtualpc draaide, en die was vele malen(!!) sneller dan de out of the box installatie van 95 (nadat het systeem opgestart was in ieder geval). En maakte gebruik van 2 CPU cores op 2,1GHz.

Deze virtual machine werd gebruikt om oude 8bit software te kunnen blijven gebruiken, En draaide/bootte uiteindelijk in de virtualpc sneller dan native op de machine (athlon XP 2000+)

[Reactie gewijzigd door un1ty op 23 juli 2024 02:34]

[Jack Flushell]

Mijn Voodoo had wel degelijk een koelblokje erop...

[Neko Koneko]

Voodoo 2 kaart gehad waar geen koelblok op te vinden was.

edit: het hing trouwens ook af van de fabrikant of de kaart koeling had, en latere voodoo kaarten (Voodoo3/4/5) hadden het volgens mij gewoon allemaal.

[Reactie gewijzigd door Neko Koneko op 23 juli 2024 02:34]

[juwecamu]

Toevallig een tijd geleden mijn VooDoo1 en 2 verkocht via V&A en daarbij foto's geplaatst.
Beide zonder extra koeling:
V&A aangeboden: 3Dfx Interactive Voodoo 4 mb PCI
V&A aangeboden: 3Dfx Interactive Voodoo2 12 mb PCI

[Prozaq]

Nee, ik denk eerder het omgegkeerde. Programmeurs in die tijd moesten wel het onderste uit de kan halen wat betreft de CPU. Er werd relatief veel in machine taal gewerkt (laagste nivo om te programmeren) voor kritische onderdelen van programma's, Je ziet juist dat tegenwoordig zeer ineffectief wordt geprogrammeerd omdat de CPU toch snel genoeg is en de compiler je meer aan het handje houd.

[the_stickie]

Programmeurs uit die tijd moesten wel efficiënt programmeren om met de beperkte resources iets tof te kunnen doen.

[ro8in]

Spellen waren juist veel beter geoptimaliseerd dan vandaag de dag. Er was amper headroom voor minder geoptimaliseerde games. Veel dingen werden zelfs nog in assambler geschreven omdat daarmee simpel weg beter te optimaliseren viel. De eerste roller coaster tycoon is bijvoorbeeld grotendeels in assambler geschreven nog.

Daarnaast was het natuurlijk ook nog te doen om alles uit de cpu te halen, alles was immers een stuk simpeler. Er bestonden geen ingewikkelde instructie sets en uitgebreide sdks als laag ertussen. Alles werd nog bare metal geschreven. Het was dan ook vaak een kwestie van je hardware naar de game zetten ipv de game naar je hardware zoals vandaag de dag normaal is.
Bij veel games moest je in de config aanzetten of je een soundblaster geluidskaart had en of je cpu mmx ondersteund etc. Stond je hardware niet bij het lijstje dan had je pech. Kon je of zonder geluid spelen of een kaart gaan kopen die er wel bij staat.

Dingen als directX etc hebben veel van deze problemen opgelost en games programmeurs konden veel universeler gaan schrijven, met als nadeel een stuk slechtere optimalisatie wat wij maar voor lief hebben genomen.

Overigens zie je wel dat de trend nu langzaam weer meer naar bare metal aan het gaan is omdat vrijwel al onze pc's weer identieke hardware bevatten. Er is niet meer zoveel verschil tussen cpu's, geluidskaarten, gpu's etc zoals dat vroeger was. Hardware is vrij universeel geworden en zit het verschil em meer in snelheid en geheugen, maar kwa instructie sets etc is er niet zoveel verschil meer, iets wat vroeger nog wel anders was..

[Reactie gewijzigd door ro8in op 23 juli 2024 02:34]

[Verwijderd]

Wat betreft die cycles, het is nog maar de vraag of spellen in die tijd wel echt effectief de CPU gebruikte. Ik heb echt nul verstand van hoe dat destijds ging, maar het zou me niet verbazen als spellen heel beperkt gebruik maakte van de mogelijkheden van de CPU.

Pinball Fantasies (1992) draaide prachtig op 80286 op 12 Mhz, met prachtige soundtrack (die zelfs goed klonk via PC speaker; hetgeen dus weer meet clock cycles betekende, om de PC speaker dergelijke audio af te laten spelen) en is in zijn genre een legendarische titel. Die echt alles maar dan ook echt alles uit je CPU haalde wat er maar in zat.

Voor grappige volledigheid, de OST: https://www.youtube.com/watch?v=Yml8PLtFyy4

Ander voorbeeld, Quake 1 -- draaide ook volledig op CPU en was zo zwaar geoptimaliseerd dat in de ontwikkeling ervan dat er echt werd gevochten voor individuele clock cycles.

In die tijd was men juist veel meer bezig met het volledig uit elkaar trekken van een CPU om er echt alles uit te halen dat er in zat. Anno nu lijkt men soms niet eens meer de moeite te willen nemen; als ik kijk naar een Hearthstone: Heroes of Warcraft dan vliegt het glazuur mij van de tanden; het presteert hopeloos slecht in vergelijking met, bijvoorbeeld, Diablo III. Op mijn GPU-loze systeem kan ik prima D3 spelen maar Hearthstone is echt opvallend traag in vergelijking met hoe het presteert op een volledig systeem.

De belangrijjkste "spel" gerelateerde software anno nu waarvan ik wel oprecht kan vaststellen dat er wordt gevochten voor iedere instructie, om die zover mogelijk te optimaliseren is binnen chess engines.

[knirfie244]

En dan kom je met een link naar de 5x86...

Ja, deze processor was compatible met het oude Socket 3 voet en de meeste 486 moederborden, en het was niet veel meer dan een geoptimaliseerde 486. Maar officueel was het AMD's opvolger op hun 486 en hun antwoord op de op de Pentium, die ze niet meer mochten kopiëren.


Daarnaast:

Produced From November 1995 to 1999

Toen was Windows 95 er dus al. Kleine kans dat Windows 95 ontworpen was om daar op te draaien.

[Reactie gewijzigd door knirfie244 op 23 juli 2024 02:34]

[Verwijderd]

De eerste pentium was toen high-end, en 486DX/2 was net midrange(Zo'n drie jaar daarvoor lang de standaard geweest), en nog volop te koop. Zowel intel als AMD maakten nog een DX4, voor AMD met de 5x86 kwam. de K6 was uiteindelijk de tegenhanger van de pentium, en IBM had nog hun 6x86 series.

Niet elke 486 gaf dezelfde prestaties, omdat er ook nog geschakeld werd met een 25/33/40mhz bus, en cache op het mainboard gemonteerd moest worden.

Maar windows95 op een 486DX2 met 8MB(100+ gulden per MB destijds) was redelijk de standaard rond de release van windows95. Het OS draaide(kroop) ook nog op een 386.

[Xfade]

De 5x86 was de tegen hanger van de Pentium 75 (Am5x86-P75), K6 voor Pentium 2.
Leuk spul. Had ik destijds met een socket converter draaien. Jammer dat je dat niet meer ziet.

[Nazanir]

Dat is niet bepaald een sterk argument.

Ik draaide Windows 95 vroeger prima op een 486DX-100, met een kloksnelheid van 100Mhz. Dat was singlecore, dus een dualcore van 266 is meer dan toerijkend, echter zal Windows 95 daar geen gebruik van kunnen maken, want deze is geprogrammeerd voor single thread, want dual (of meer) bestond toen gewoon domweg niet.

Het grootste probleem is denk ik dat de hardware gewoon niet compatible is, onbekende processor instructies, geheugen toewijzingen, etc. En dit gaat natuurlijk meer om "proof of concept", of beter gezegd: "omdat het kan".

Wat dat betreft vind ik dit soort dingen altijd leuk om te lezen.

[Exorcist]

Dual CPU's kwam rond de Pentium (1), dus nog wel in het '95/'98 tijdperk. Echter was destijds alleen NT4 of later (2000, XP etc.) geschikt voor twee CPU's.

[Mijzelf]

Compaq had in 1989 de SystemPro, een dual 386 systeem. Windows NT 3.1 kon daarop draaien.

[Sleurhutje]

Had DEC ook niet een systeem met dubbele 486?

[equit1986]

niet omdat het moet, .......


maar omdat het kan........


Kon het niet laten.
on-Topic:
Je had in die tijd ook al multi-CPU setups, alleen was dat voor NT-servers, ik weet eigenlijk niet op Win95 overweg kan met multi-cpu(wat multicore eigenlijk is).

[Verwijderd]

ik weet eigenlijk niet op Win95 overweg kan met multi-cpu(wat multicore eigenlijk is).

Nee, zie: https://en.wikipedia.org/...ndows_versions#Windows_9x

[Mizgala28]

De boel wordt gewoon geëmuleerd, daarom draait het traag.

[rjberg]

En dat is dan ARM, dus je moet ook nog emuleren voor x86.

Om maar te zwijgen over het feit dat er waarschijnlijk geen hardware versnelling is en dus de cpu graphische berekeningen moet uitvoeren.

[Peetz0r]

en dus de cpu graphische berekeningen moet uitvoeren

Ja hallo, we hebben het hier over de windows 95 desktop. De benodigde berekeningen kan ik op papier voor je uitvoeren.

Ik denk dat het probleem overal zit behalve hier

[Verwijderd]

Nou die berekening wil ik wel graag zine van je dan....

[Peetz0r]

Nou, ongeveer dit:

1. Pak de waarde voor een of ander vieze zeegroene tint. Plaats deze (640*480) 307200 keer in het geheugen.
2. Pax de bitmap van dat ene geheugenadres en plaats deze op dat andere geheugenadres. Herhaal dit zovaak als er icoontjes op de desktop staan. Je zult wat moeten optellen en vermenigvuldigen om de juiste adressen te vinden voor de locatie. Je hoeft niks te doen qua compressie, scaling, rendering van svg's, of andere hippe shit, dat doen we de volgende eeuw wel.
3. Voor al die bovenstaande icoontjes, render ook een bepaalde tekst in een of ander font. Dit font, zijnde een stapeltje bitmaps, staat al ergens in je geheugen. Maak je niet druk over antialiasing, subpixels, scaling, schaduw, of watdanook. Dat doen we over 10 jaar wel.
4. Teken onderaan een of andere grijze rechthoek van 24*420 pixels. Teken aan de bovenste rand een schaduw. Wat is dat? Nou, een paar lijntjes in een wat donkerdere tint aan twee zijdes, en een lichtere tint aan twee andere zijdes. Zwart en wit volstaan hiervoor.
5. Teken de start-knop linksonder. De bitmap hiervoor staat ook al ergens in het geheugen. Kies de niet-ingedrukte versie van die bitmap.
6. Teken rechtsonder een paar bitmaps voor icoontjes zoals netwerk, audio, etc. Oh wacht, er is geen netwerk of audio in onze geëmuleerde pc? Laat maar zitten.
7. Render rechtsonder wat cijfertjes, een dubbele punt, en nog wat cijfertjes. Het font dat je in stap 3 gebruikt hebt volstaat, maar kies wel ff de kleur zwart ipv wit.

Klaar!

(Todat er een minuut verstrijkt, herhaal dan stap 7).

Als je meer had verwacht, installeer dan Windows XP. Dan krijg je grotere bitmaps, meer kleurdiepte, en anti-aliasing. Is dat niet genoeg? Installeer dan Windows Vista. Jeweetwel, met al dat hippe glas dat in virtuele machines nog steeds vaak niet werkt...

Disclaimer: natuurlijk is bovenstaand stappenplan enorm versimpeld, en natuurlijk is het zo interactief als een baksteen (met een horloge, dat wel), en naturlijk kan ik niet de staat van >300.000 bytes op papier bijhouden. Maar echt moeilijke of talrijke berekeningen is geen sprake van.

[Reactie gewijzigd door Peetz0r op 23 juli 2024 02:34]

[Marctraider]

Een beetje extreem over versimpeld... Nou was nummer 1 wel weer grappig. Dat ging pas bij ME/2000/XP naar een wat acceptabelere blauw waarde

[Reactie gewijzigd door Marctraider op 23 juli 2024 02:34]

[Mizgala28]

En daar is een CPU slecht in, veel DS emulators gebruiken de cpu voor emulatie waardoor het enorm inefficiënt is, waar de DS een dood en dood simpele hardware voor gebruikt.

[Verwijderd]

Destijds had ik een Pentium 100 met 16MB EDO RAM en dat trok Windows 95 als een trein

[Fermion]

Voor de lol zal ik weer is W95 op VMWare installeren. Heb er een lange tijd mee gewerkt totdat W2000 uit kwam, want alles daartussen was een brakke boel.

[Exorcist]

Ik heb W95 ook op VMWare draaien puur voor de nostalgie. Ook 98, ME en alles daarboven overigens. Maar, brake boel? Windows 98SE was far more stabiel dan 98 en zeker 95. ME daarentegen heb ik nooit heel stabiel kunnen krijgen, alsof je een vrouw hebt die snel aangebrand is en bij het minste geringste je in de haren vliegt. Je moest er heel voorzichtig mee omgaan

[Verwijderd]

Lucky bastard, moest t tot eind 96 nog met een 486 doen. Had geen geld voor een nieuwe. Die 486 had me al een rib uit mn lijf gekost. Heb nog zelfs een elektuur schema gebouwd, zodat je de Mhz in het scherm kon faken. Nou dan kon ik er weer even mee vooruit en pronken als iemand langs kwam. Totdat iedereen om me heen Pentiums begon te kopen

[Mizgala28]

Afhankelijk welke 3DS, de New 3DS is een 532mhz dual core met 256mb ram en 10mb videokaart, waar de oude een 266mhz (correct me if I'm wrong) dual core is met 128mb ram en een 6mb gpu.

(Wel een WTF moment, dit is stukken cooler dan W95 op een smartphone of smartwatch)

Ik ben benieuwd of ze ook voor de gein Windows 95 (of ander OS) op PS Vita kunnen draaien, die is 800mhz quad-core met 512mb ram en 128mb gpu.

Cool dat dit kan.

[Nas T]

Ik ben benieuwd of ze ook voor de gein Windows 95 (of ander OS) op PS Vita kunnen draaien

Maar niet benieuwd genoeg om het op google in te tikken?
klikkerdeklik

[Mizgala28]

Blijkbaar heb ik dat gemist

Echter wel teleurstellend dat het niet werkelijk op de Vita draait maar in de PSP emulator, die benut de snelheid van de Vita niet en draait even snel als een normale PSP dus zal dit net zo (snel) werken als op een PSP.

Wat ik wil zien is werkelijk op de Vita hardware draaien van een ander OS, alleen dan benut je de gehele hardware.

[Reactie gewijzigd door Mizgala28 op 23 juli 2024 02:34]

[Nas T]

Het is de eerste hit als je zoekt op "ps vita windows 95"...

[Mizgala28]

Zie boven wat ik net zei.

[Aetje]

Je vergelijkt appels met peren. De ARM processor die in een 3DS zit is een RISC (Reduced instruction set computing) processor, reduced instruction set. Deze typen processors voeren meer berekeningen per seconde uit, maar kunnen complexere taken niet aan - deze moeten in meerdere berekeningen worden opgesplitst om een CISC machine taal te emuleren. RISC CPUs draaien op een hogere core klok dan CISC processoren met een vergelijkbaar prestatieniveau.

[Pepsichoco]

Men doet dit wel zomaar, maar mag dat eigenlijk wel. Zijn er aan Windows95 geen gebruikersvoorwaarden die dit niet toelaten ? Ook al wordt Win95 al lang niet meer ondersteund.

[blorf]

Volgens mij mag iemand met een officiele Window 95 licentie uitproberen wat hij wil. De complete oplossing inclusief de Windows systeembestanden te downloaden aanbieden is vanwege de nog steeds geldige copyright volgens mij nog altijd verboden. Zo ook het delen van informatie die verkregen is met reverse engineering, maar ik denk niet dat ze hiervoor aan Windows zelf aanpassingen hebben gemaakt.
Ik vind persoonlijk de keus voor Win95 als target nogal jammer. Moet je kijken wat Linux kan doen met soortgelijke specs. Daar heb je tenminste iets aan.

[thedicemaster]

linux is er ook al(en ook voor de DS)

windows werkend krijgen is vooral interessant omdat het gesloten is en harde minimum eisen heeft.
linux kan je eenvoudig schalen naar oudere hardware door wat te rommelen met de source en bijgeleverde programma's.

[thegve]

In ieder geval binnen de EU is er vrij veel mogelijk met reverse engineering.

http://digitalcommons.law...rticle=1134&context=chtlj

The Directive as adopted authorizes decompilation under limited conditions. As a result, European software producers may have greater access to the inner workings of American computer programs without the risk of facing an injunction aimed at preventing the European product from being marketed. For example, the Directive permits decompiling a computer program where reproducing the code is "indispensable" to figuring out how to connect a compatible product.
Exactly what information is indispensable may be left to the interpretation of the courts in years to come when a product created with the help of reverse engineering analysis competes too fiercely with or replaces an established product in the marketplace.

'Freedom of information' is overigens een behoorlijk heilig recht binnen de gehele westerse wereld, ik kan mij slecht voorstellen dat informatie, hoe dit ook verkregen is, niet gedeeld zou mogen worden.
Zelfs als die informatie gebruikt kan worden voor criminele doeleinden kan die informatie zelf al bijna niet verboden worden.

[Reactie gewijzigd door thegve op 23 juli 2024 02:34]

[mr01z0]

Awesome vergeet niet dat in de tijd van Windows 95 een Pentium 90 of 133 nog steeds heel normaal was, betaalbare dual core processors had je niet echt voor thuis.

[Verwijderd]

De eerste dual-core x86 CPU kwam pas in 2005. Van AMD.

[Bokkiej]

Nu nog een 3DS emulator draaien op die Windows 95 en de cirkel is rond

[beerendlauwers]

Ik vraag me af wat het record is voor nested emulators / vms

[stefanhendriks]

Gaaf dat dit kan. Jammer dat we geen actie zien in het filmpje naast het booten. Nog gaver zou zijn (maar lijkt mij technisch on-.. uitdagend) om native Win95 te draaien op dos op de 3ds. Ipv via dosbox. Ik heb het idee dat zodra dosbox kan draaien dat je daarna alles kunt wat je normaal in dos kan/zou kunnen. Bijv je zal ook Quake, C&C, Dune (2), Commander Keen, Wolf3d etc... kunnen draaien. In die context is het draaien van Win95 misschien niet eens zo spannend?

Zal waarschijnlijk ook traag zijn door deze emulatie. Misschien dat dosbox van de 2 cores van de 3ds gebruik kan maken, maar Win95 (of dos programma's in algemeen) werken single core dus het zal niet (nooit?) heel snel zijn. Tenzij er een manier wordt gevonden om de emulatie middels hardware te doen (zoals VM's met hardware virtualisatie doen?)

[Reactie gewijzigd door stefanhendriks op 23 juli 2024 02:34]

[Alex3]

Windows 95 is geen MS-DOS-programma, het is 32-bits. Dat je MS-DOS kunt draaien, betekent niet dat Windows 95 werkt.

[680x0]

Win 95 had de 32bit MS-DOS Cougar kernel...

[Dj Neo Ziggy]

Nintendo kennende zal dit wel snel de kop in worden geduwd. Zo had ook iemand een tool geschreven voor het emuleren van amiboo's . De uitgever durfde niet eens de code op Reddit te zetten zonder rechtzaak

[thedicemaster]

ja en nee.
windows op 3DS doen ze niks tegen.

wel zijn ze druk bezig met het voorkomen dat homebrew gestart wordt, waarom 1 ongevaarlijke homebrew pakken wanneer je met een eshop pull of systeem update meteen alle homebrew en piraterij beperkt of platlegt?

[Verwijderd]

Ik vraag me af waarom het zo traag gaat. Als ik terugkijk naar de pc waar ik destijds W95 op draaide (en vooral OS/3 Warp) dan was dat een pentium 60 met 8MB RAM geheugen. De N3DS zou hier rondjes om moeten draaien met 2 vingers in de neus.

[thedicemaster]

tot je bedenkt dat de n3DS hier met effectief een Chinees-Engels woordenboek zit te werken.
W95 is ontworpen voor een heel andere processor architectuur, waardoor de n3DS heel veel moet vertalen.
linux en android 1.# zullen soepeler werken, omdat ze voor de juiste architectuur gecompileerd kunnen worden.(en linux is een stuk makkelijker te strippen)

[Nitramuse]

Doet me denken aan de PSP. Die had dit ook en liep ook aardig traag.

Ik denk niet dat dit verder word ontwikkeld, kan me niet voorstellen dat je via W95 x86 emulatoren gaat gebruiken. Je moet dan toch ook drivers voor je 3DS gaan bouwen? Lijkt me nogal inefficient. Maar ik ben geen engineer dus kan het fout hebbeb...

[thedicemaster]

het draait in een dosbox, en die zal nog wel verder ontwikkelt worden vanwege een aantal oude DOS spelletjes die nog best leuk zijn.

de Windows kant hoeft niet verder aan gewerkt te worden.

[Templar]

Als referentie:
Ik had windows 95 draaien op een 486dx2/66Mhz met 8 MiB aan geheugen. En met een Trident TGUI9440 1 MiB 2D videokaart

[Reactie gewijzigd door Templar op 23 juli 2024 02:34]

[680x0]

Jij had geen 8MiB geheugen , jij had 8MB geheugen.. ofwel 8192KB en geen 8000KB.

[reddevi009]

Maar dan andersom. 8 MiB staat geliik aan 8192KB.

[680x0]

Klopt, ik haalde ze weer door elkaar. Blijft trouwens een belachelijke discussie. IT werkt binair, niet decimaal.