<åt sidan class = "s-notice s-notice__info js-post-notice mb16" role = "status">

Stängt . Denna fråga är opinionsbaserad . För närvarande accepteras inte svar.

Kommentarer

  • Är det inte ' t som bara ber om åsikter? När allt kommer omkring är alla vägar nu väsentligen lika med vad de kan producera som användarupplevelse.
  • För det måste du definiera vad du anser vara en teknisk anledning. Det finns inget svar utan en tydlig definition vad som frågas.
  • @Raffzahn Extrahera från ett annat svar: " Programvaruemulering kan fungera ganska bra, men kommer att vara begränsad till gränssnitt med hårdvara som emulatordesignern känner till. En bra FPGA-baserad rekreation kan gränssnitt med nästan alla typer av vintage-hårdvara, inklusive enheter som FPGA-designern inte vet något om, samtidigt som den erbjuder bättre tillförlitlighet än vintage-hårdvara. " Detta är ett bra exempel av teknisk anledning. Jag tror inte ' att " teknisk anledning " är ospecificerad. Det är allt som är objektivt sant snarare än någon ' s egen uppfattning om verkligheten som kan beskrivas som " åsikter ".
  • Förutom att ' inte är ett tekniskt skäl utan ett underförstått användningsfall, här för att bifoga ' annan ' hårdvara. Eftersom det här alltid behöver uppdateras (även med den verkliga hårdvaran är det ' inte heller något specifikt för emulering.
  • @Raffzahn: När du använder en FPGA-enhet som exakt efterliknar det ursprungliga beteendet på hårdvarunivå, ingen uppdatering krävs för att arbeta med hårdvara som FPGA-programmeraren inte vet något om.

Svar

En fördel som FPGA-emulatorer i allmänhet delar med gammal hårdvara är möjligheten att använda enheter som interagerar med hårdvaran på sätt som är mycket tidsberoende. Till exempel om man har en spelkassett för NES som utlöser ett avbrott varje gång den första dataraden för en viss sprite hämtas, en konsol som läser upp innehållet i en patron och sedan emulerar att den bara skulle kunna spela spelet korrekt om den kunde känna igen vad patronen gjorde med avbrottslinjen.

FPGA-baserad maskinvara skulle i allmänhet fungera lika bra som, om inte mer pålitligt än, vintage hårdvara, men det finns några konstiga konstigheter att tänka på. Några prototyputvidgningskassetter för Atari 2600, till exempel, förlitade sig på det faktum att även när NMOS 6502 försöker dra databussen högt, är den oförmögen att försöka tillräckligt hårt för att antingen övermäta en extern enhet som försöker dra linjen lågt eller skada sig själv i försöket. Observera att det omvända inte är sant: en NMOS-enhet som försöker dra en linje låg medan en extern enhet drar den högt kan skada sig själv i försöket (RIP 2600jr). Om man skulle ansluta till ett modernt rekreationssystem en NMOS-enhet som förlitade sig på förmågan att överdriva bussledningar, och systemet begränsade inte högströmströmmen på dessa ledningar, kan det skada den externa enheten. t vet i vilken utsträckning det faktiskt skulle vara ett problem, men eftersom alla enheter som förlitar sig på sådana tekniker förmodligen är sällsynta, skulle det vara mycket olyckligt om de skadades.

En annan potentiell fråga är att vintageelektronik var ofta ganska långsamt att svara på signaler, vilket innebar att om en enhet skulle ge en signal mycket kort på en tråd, skulle den sannolikt ignoreras. Vissa vintageelektronik skulle ibland mata ut korta glitchpulser om någon kombination av ingångar ändrades mellan ett tillstånd där utmatningen skulle vara låg och ett annat tillstånd där utmatningen skulle vara låg. Om en FPGA-rekreation inte är avsedd att ignorera sådana pulser kan de orsaka felaktig användning på den återskapade hårdvaran trots att de inte skulle ha orsakat några problem på originalet.

Personligen tror jag att FPGA är det bästa sättet av återskapande system. Vintagemaskinvara är cool, men tillförlitlighet är ofta problematisk. Programemulering kan fungera ganska bra, men kommer att vara begränsad till gränssnitt med hårdvara som emulatordesignern känner till. En bra FPGA-baserad rekreation kan gränssnitt med nästan alla typer av vintage hårdvara, inklusive enheter som FPGA-designern inte vet om samtidigt som den erbjuder bättre tillförlitlighet än vintage-hårdvara.

Svar

Förord: Frågan sömmar för att fråga om åsikter, eftersom det är en åsikt om någon accepterar en emulering, oavsett om programvara på en CPU eller en FPGA, som samma sak som den riktiga saken eller inte.

Fråga dig själv, kör en modern teknikbil pimpad upp för att se som en SSK samma som att köra den riktiga saken? Vill du åka på en BMW från 1950-talet med alla dess ljud, dofter och vibrationer (och allt som behövs för att hålla det igång) eller en elcykel från 2020 som gör att den ser ut som en, vilket ger dig det klassiska ljudet från en inbyggd iPod ?

Jag vandrar vad är skillnaderna mellan att använda en riktig hårdvara, FPGA-baserade hårdvaruemulatorer som MiSTer och den stora mängden programvara emulatorer för olika system som körs på moderna Windows-, MacOS- och Linux-datorer.

Om du bara är en användare, övertygad om att använda ditt moderna tangentbord och moderna mus hantera en bild, som ser ut som 640 x 400, på din 4k-skärm, då är programvara allt du behöver. Redan en FPGA-version kommer att vara överdriven, eftersom den använder samma moderna enheter.

Å andra sidan , om avbildning inte räcker, men du vill känna den skrymmande Atari-musen, det vackla Amiga-tangentbordet eller den skrymmande C64-joysticken, allt presenterat med riktig CRT-bländning, så finns det inget annat sätt och få den riktiga saken.

En sak som jag tänkte på är att både programvaru- och hårdvaruemulatorer inte kunde vara tillräckligt exakta

Nu är de det. i varje detalj. Modern hårdvara är tillräckligt snabb för att tillåta användning av HLL-programvara för att få exakt timing. Särskilt när all in och output emuleras ändå, mappad till moderna enheter.

Men det här verkar för mig som något beroende på kvaliteten på implementeringen som kan varierar mellan olika emulatorer och förbättras med tiden på grund av felkorrigering, men inte som en grundläggande fråga.

Låg programmering och underhåll gör inte ogiltig förfarandet. För alla ändamål, förutom riktiga händer på hårdvara, är det ingen skillnad.

Jag hör också om latensproblemet med programvaruemulatorerna, men jag ”lite förvånad över att något som detta verkligen kan kännas på en dator som förmodligen är miljoner gånger snabbare än den emulerade maskinen.

Kanske hundra gånger, om alls. Tänk på att de flesta huvudkomponenterna inte har blivit så mycket snabbare – och det mesta har äts upp av enheter av större storlek och behov av data.

Latency-frågan är något som har funnits sedan som alltid. Det kommer alltid att finnas några som säger att de kan se / känna skillnaden. Även om detta kan vara sant i några få, mycket dedicerade situationer är det skräp för det mesta. Att hävda att man känner några mikrosekunder, när man testar en joystick redan kan kosta mer är helt enkelt fantasi. >

Finns det verkligen en teknisk anledning att föredra verklig hårdvara eller FPGA-baserad emulering kontra mjukvaruemulering

Vad utgör en teknisk anledning för dig? I sig är begreppet inte klart när man jämför olika implementeringar.

eller det här är bara en nostalgi sak, orsakad av önskan att fylla som du är verkligen tillbaka på 80-talet eller 90-talet?

Har du någonsin satt framför en av de gamla maskinerna? Det är förvånande hur olika tangentbord känns när man lämnar dagens standardutrustning.

Och så finns det naturligtvis hårdvaran som tippar – inte riktigt kul med emulatorer, eftersom det här bara är att lägga till några rader med att lägga till ett gränssnitt kod – eller bara konfigurera på i vissa fall. Ingen layout, inte etsning, ingen lödning och särskilt ingen förbannelse och lapp tills den fungerar.

Svar

Jag skulle vilja klargöra termen ”FPGA-emulering” som nämns i frågan.

Först, naturligtvis finns det sådant som mjukvaruemulering. Låt oss ta ett exempel på några (mer eller mindre) exakta programvaruemulatorer av 6502 CPU . De försöker emulera alla externa artefakter från den verkliga CPU, såsom antal cykler per kommando, adresser till minnesåtkomst och till och med ”internt tillstånd” (snarare bara tillståndet för programvarusynliga register). Ändå har den inget liknande med den riktiga processorn, från och med den punkten är det ren programvarufråga, inte hårdvaruenhet.

När någon ny funktion i real 6502 upptäcks (som nya okodade opkoder eller flaggor eller exekveringsdetaljer ) sätts den in i programvaruemulatorn som ”en annan funktion att implementera”. Inga särdrag hos den verkliga saken kommer att utvecklas i programvaruemulatorn, om de är okända för implementatören.

Låt oss sedan titta på 6502-kompatibla HDL-kärnor.De representerar nu faktiskt en riktig digital logisk enhet – eller en modell av det (om HDL är simulerad, inte implementerad i den verkliga hårdvaran som FPGA eller ASIC). De har nu riktig flipflop (eller spärr) lagring för CPU-register, de kan implementera riktiga CPU-bussignaler och till och med sättas in i retrodatorn istället för originalet 6502. Ändå är de gjorda (mer eller mindre) ”från grunden”, med specifikationerna för den CPU som de är avsedda att ersätta, inte dess interna struktur. Och ändå skulle de sakna funktioner som inte beskrivs i de specifikationerna, som finns i riktig retro-CPU, men som ännu är okända för implementatören.

En annan nivå av rekonstruktionen kan vara HDL-designen byggd på följande sätt:

  1. verklig retro-CPU avkopplas och fotograferas
  2. sedan återskapas nätlist- och transistornivåscheman (antingen för hand eller med några mer eller mindre automatiserade verktyg)
  3. netlist konverteras till gate level schematics och sedan till HDL beskrivning, som i sin tur implementeras i FPGA eller ASIC.

Till skillnad från tidigare fall, nu nästan alla funktioner i den verkliga CPU bli implementerad ”nativt”, eftersom strukturen för den resulterande HDL är mer eller mindre likvärdig med strukturen för den verkliga saken (vid logiska grindar och flipflopsnivå).

Fortfarande kan det finnas problem, till exempel 6502 har några instruktioner som beter sig oregelbundet och jag känner att sådant beteende inte skulle dyka upp i HDL naturligt.

Generellt sett ansåg jag allt över ”reverse engineer, then recreate HDL” är faktiskt en emulering , antingen i programvara eller hårdvara, medan det senare är inte .

Med andra ord, låt oss överväga att bevara den gamla programvaran. Vi kan köra den på modern hårdvara, men om den inte är tillgänglig kommer programemulatorer att spela, men den gamla programvarustycket de används för att köra är fortfarande exakt densamma.

Nu vill vi bevara gammal maskinvara (CPU), men den autentiska implementeringen är inte tillgänglig, så vi återskapar den med nyare teknik, men processornas logiska struktur förblir exakt densamma.

Svar

För att endast erbjuda svar på latensfrågan, som emulatorförfattare:

Undantag finns i överflöd men den allmänna regeln för originalhårdvara från 80-talet och in tidigt på 90-talet är att joypad- och tangentbordsinmatningsändringar kan detekteras av hårdvara nästan omedelbart efter det att de inträffar, och att när video och ljud matas ut från maskinen når det användaren nästan omedelbart – t.ex. för en klassisk CRT-tv så är nivån att måla just nu är nästan maskinens live-utdata.

Med hårdvara nu passerar ingången i allmänhet är en Bluetooth- eller USB-stack, som bara kan inspekteras vid ett visst intervall av värd-operativsystemet, och om något har hänt kommunicerar det sedan vidare till den intresserade processen som kan eller inte kan hända omedelbart beroende på den specifika schemaläggaren.

Många emulatorer implementerar också en huvudslinga som ser ut som hur du kan utforma ett spel:

  1. samla alla senaste ingångar och vidarebefordra den till den emulerade maskinen;
  2. kör maskinen efter en ram;
  3. måla nästa utmatningsram till en osynlig buffert;
  4. kö som visas för nästa vsync och block;
  5. upprepa.

För argumentets skull, föreställ dig att din moderna maskin är väldigt snabb och att steg 2 och 3 är omedelbara. Sedan:

  • det finns en genomsnittlig halv ram med ingångsfördröjning plus vad som helst Bluetooth / USB-signalering och operativsystemet som läggs till – alla ingångar som inträffar strax efter att toppen av en ram kommer inte att vidarebefordras fram till början av nästa kommuniceras allt som inträffar precis i slutet nästan vid rätt tidpunkt, och intervallet för latenser däremellan är linjärt så medelvärdet är halvvägs mellan; och
  • det finns en fast extra ram för utmatningslatens eftersom du lägger upp en ram för presentation vid nästa vsync och sedan väntar tills det är dags att visas.

Så med den enkla slingan, på ideal hårdvara, är i genomsnitt fallet fördröjningen mellan att du trycker på något och skärmen reagerar cirka 1,5 bildrutor mer än riktig hårdvara. Och det är bara om värd- och emulerade maskiner körs med samma bildhastighet .

Purister hävdar att vissa originalspel är så finjusterade, efter lämpligt antal timmar som testats och justerats tillbaka på dagen, att 1,5 bilder ger dem en nackdel som de kan upptäcka.

FPGA är vanligtvis * -emulering, oavsett hur de säljs, för de är vanligtvis en person som implementerar en specifikation på ett högnivå-språk för hårdvarubeskrivning. Men de försöker att utelämna så mycket av den latensen som möjligt – en bra kvalitet kommer att utelämna videobufferten helt, köra resten av systemet i realtid och trycka in inmatningen med minimal fördröjning.

* kvalificering läggs till enligt den korrigering som tillhandahålls av @lvd nedan. Se hans svar för mer färg.

Naturligtvis är det inte svårt att lösa de flesta programvaruproblemen i programvaran:

  • vidarebefordra inmatning oftare;
  • don använd vsync för att utlösa ny utdata till vsync; och
  • använd inte en dubbel buffert.

I extremis kan du till och med tävla med rastern för liknande utmatningslatens till en FPGA – om du redan har en hög -frekvensslinga för frekvent inmatning, och om bashårdvaran stöder någon form av utdata som kan ge skärmavrivning, så har du verktygen.

Tyvärr användes sådana metoder vanligtvis inte av emulatorer i tidigare, särskilt innan latens blev ett så omfattande diskuterat ämne, och något av en negativ bild har fastnat.

Kommentarer

  • FPGA är inte alltid en emulering, åtminstone i dina termer av " en person som återimplementerar en specifikation i ett högnivåbeskrivningsspråk för maskinvara "
  • @lvd för att förbättra svaret, kan du vara mer specifik? Jag ' är medveten om ett experiment som använde en netlista extraherad av VisualChips från en riktig (om minnet tjänar ) TIA, men lite utöver det. EDIT: nej, vänta, jag ser att du ' har lagt upp ett separat svar. Tack!

Svar

många aspekter av HW vs SW har täckts av andra inlägg här så jag kommer inte röra vid dem. Istället skulle jag vilja förklara LATENCY frågan från min synvinkel tillsammans med erfarenheter jag fick under kodning av mina emulatorer för olika plattformar …

Att göra SW-emulator på moderna maskiner är mycket svårare från latensaspekt än det var tillbaka under direkta I / O-åtkomsttider. För hemdatorer och spelkonsoler behöver vi simulera / emulera ljud, visuell utmatning och användarinmatning så exakt som möjligt. Det största problemet är med ljud. Det beror på att vår hörsel är mycket bättre än någon annan av våra sinnen och vi kan känna / höra skillnaden om ljudet är avstängt med några få ms eller Hz. Om skärmen är avstängd med 1 eller 2 bilder kan vi inte se skillnaden. Även om ingången är försenad en liten bit är det ok (för de flesta människor).

I modern maskinarkitektur är allt buffrat (särskilt ljud). Så för att mata ut ljud måste vi skapa en PCM data som skickas över till ljudchip och spelas upp genom DMA + DAC . För att göra detta används vanligtvis två cirkulära eller många små linjära buffertar. För att producera glitchfria ljud måste buffertarna vara tillräckligt stora. Till exempel i Windows förra gången jag kontrollerar WAVEOUT behöver minst 20-80 ms. DirectSound behöver >400 ms

Nu om det emulerade programmet justerar ljudutmatning kommer det att matas ut först efter att det redan tillfrågade ljudet spelats ut.

Detsamma gäller för I / O-ingång på vissa plattformar så att förseningarna läggs till.

När du använder FPGA så har du direkt tillgång till ljudutgången utan buffring. Detsamma gäller för inmatning.

Men spel ingångslatens (tangentbord, joystick) har vanligtvis inget att göra med värdet för värdsystemet . Den vanliga orsaken är att majoriteten av emulatorerna använder klocktics för att upprätthålla emulerade hastigheter. Så de simulerar CPU eller vad som helst och når en gång önskat antal simulerade klockor per gång de sover tills nästa timer har utfärdats eller vad som helst. Ju snabbare värddatorn är, desto mindre tid behöver den emulera, därför kommer inte simuleringen att reagera större delen av realtiden.

Låt oss till exempel anta att vår simulering kan köras 100 gånger snabbare än originalhastigheten på den emulerade datorn. Det betyder att bara 1% av tiden gör simuleringen något och vilan är bara Sleep(). Under sömnen kan emuleringen inte svara på någonting. Så det kan missa tangenttryckningar, brandklick etc … För att avhjälpa att vissa emulatorer kan använda buffring igen vilket leder till latens istället för att ignorera ingång. Det finns också olika sätt att kontrollera tiden som helt tar bort problemet. För mer information om detta ämne, se:

Svar

Vintage NTSC-maskiner (och CRT-datorer osv.) kan ändra grafikutgången mitt i CRT-skärmuppdateringen (delvis) ner den vertikala rastern), och därmed riva bilden som svar på realtidsinmatning.

Emulatorer som använder icke-CRT-skärmar kan inte göra det i realtid och kan bara fejka en riven raster nästa ram eller fält.

Och det enda sättet att testa om en emulering är korrekt i förhållande till den faktiska (mark sanningen) vintage hårdvara. Se om det finns några odokumenterade dolda logiska fällor (defusion, etc.) eller analoga layoutfel under de olika ASIC-chiplagren.

Kommentarer

  • _ " .. kan bara fejka … " _ Var skillnaden? Är ' inte en emulering som handlar om att fejka hela saken?
  • Inte på en icke-CRT-skärm. En LCD (et.al.) uppdateras inte ' i 2 sammanflätade fält med 30 bilder, där alternerande linjer och övre och nedre delen av ett fönster visas vid olika tidpunkter, över 10 mS från varandra i realtid. Kanske skulle en FPGA som matar en gammal CRT-skärm vara mer exakt än en emulator.
  • Ingenting hindrar emulatorprogramvaran att göra detsamma. och vissa gör det. När allt kommer omkring är 60 Hz-skärmar nu standard, vilket gör det möjligt att överföra samma flimmer som en CRT. Inget behov av FPGA-baserad programvara eller CRT här.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *