Jeg sætter CHIP-8 frem.

Dette system er i det væsentlige en virtuel maskine, der er udviklet af en eller anden grund. Der er spil skrevet til CHIP-8. Den har et par opkoder, en stak, et par timere og en bitmapskærm med lav opløsning, men det er enkelt nok til at de første par emulatorer passer ind et par kilobyte på tidlige 8-bit computere.

Der er mere end et par referenceimplementeringer, du kan bruge.

Der er spil og så videre, som er offentligt tilgængelige. domæne allerede, ligesom her , så du ikke behøver at give dine egne spil.

Kommentarer

• Ayy for Chip 8. Det ‘ er let at finde implementeringer på mange sprog, og arkitekturen er enkel.
• CHIP-8 er en fantastisk idé til en introduktion til emu lation på grund af sin enkelhed.Efter at have skrevet en NES-emulator før, kan jeg fortælle dig, at skrivning af CPUen var ekstremt tidskrævende og kedelig – og 6502 er enkel for så vidt CPUer går. I modsætning hertil har CHIP-8 kun 35 meget enkle instruktioner. Derudover var mange systemer afhængige af præcis timingadfærd mellem CPUen og resten af hardware, mens CHIP-8 ikke har noget sådant krav.
• Kommentarer er ikke til udvidet diskussion; denne samtale er flyttet til chat .
• Jeg ‘ er en erfaren programmør, men Jeg skrev aldrig en emulator. Efter dette svar tænkte jeg: ” Hej, denne chip8 ser let nok ud, jeg ‘ Jeg bruger måske et par timer på den “. Tre uger senere er jeg ‘ stadig her og prøver at finde ud af, hvorfor programmer fortsætter med at hoppe ud af hukommelsespladsen. Masser af sjov, også masser af ” hvad fanden “.
• Jeg spekulerer på, om der ville have været nogen hindring for at fjerne vblank ventetiden fra plot-sprite rutinen og tilføje en eksplicit vblank-vent instruktion? CDP1802 er ikke ‘ en hastigheds dæmon, men det kunne næsten helt sikkert tegne mere end en sprite pr. Ramme i fravær af vblank ventetiden.

Åh. Dejligt spørgsmål. Jeg vil prøve at give et par tip, men jeg vil overveje, at spørgsmålet måde at bredde skal besvares her i stedet for en mere meningsfuld samtale. Ikke desto mindre:

---

[…] får eleverne til at oprette en emulator til et ældre system

Helt sejt.

fra bunden,

Hvis dette formodes at være virkelig fra bunden og i software, ville det ikke rigtig betragt det som en opgave, der passer til nybegyndere i en så begrænset periode. Medmindre der er en måde at udtage krav til realtid (som er endnu mere relevante for spil), ville jeg hellere være forsigtig.

Faktisk da det handler om EE, hvorfor ikke gøre ægte hardware? Det er stadig let at få (nogle) klassiske CPUer og relaterede enheder. Kombineret med som et moderne LCD-display er hardwareindsatsen ret gennemførlig på få uger i detaljer.

som et gruppeprojekt, der skal gennemføres indtil udgangen af klassen (som er som påpeget 2 semestre lang).

Hvilken kan være den mest stramme tilstand.

Jeg prøver at vælge et godt målsystem til dette projekt, hvor hovedmålet er, at det skal være ret simpelt at efterligne. Jo færre periferiudstyr, der skal emuleres, jo bedre. færre quirks og bugs, der skal replikeres, jo bedre.

Lyder som et godt forsøg. Og vigtigere, det fjerner nogle tilsyneladende enkle systemer (som singleboardere) fra listen, da de stoler på kompleks håndtering af I / O-enheder (som realtidsadgang til porte for at drive LED-segmenter på tilsyneladende kontinuerlig måde).

Jeg ønsker at udsætte de studerende for de vigtige begreber assemb ly sprog, instruktionskodning, adresseringstilstande, CPU-registre, hukommelseskortede hardware-registre osv.

Noget, der kan gøres med en ægte hardware som såvel som en emulering, er det ikke?

Ideelt set skulle det pågældende system ikke kræve cyklusnøjagtig emulering eller tricks som at jagte scanningen.

Sammen med det underforståede krav til en videooutput, kræver dette en simpel ikke-accelereret bitmap-logik.

Et andet krav vedrører ydeevne. Studerende er bestemt ikke fortrolige med softwareoptimeringsteknikker, så det at prøve at efterligne selv den første Playstation eller Nintendo 64 vil sandsynligvis løbe ind i ydeevneproblemer (måske endda SNES og Genesis).

Jeg frygter ikke meget her, da faktisk pc-hardware er ret hurtig. De virkelige problemer her er ikke emuleringshastighed, men aspekter i realtid – synkronisering af forskellige emuleringsdele – som kræver et meget omhyggeligt og finjusteret softwaredesign. Ikke at forventes her. Helt den “racing the beam” -del, du nævnte.

På dette tidspunkt behøver eleverne kun være bekymrede for at implementere emulatoren korrekt, ikke effektivt. CPU-emulering vil helt sikkert blive implementeret af en tolk, ikke en oversætter / recompiler.

Stadig, selv for de mest primitive, er realtidssynkronisering nødvendig for at spil et spil. I det mindste er en skærmretrace-synkronisering et must – ikke mindst for at skifte simuleringen i sig selv.

Det iboende behov for spil for at bruge tidseffekter – og synkroniseret skærmmanipulation på et finere niveau end rammer – er noget, der gør det at køre ethvert rigtigt spil på den foreslåede emulator til en udfordring.

Jeg vil gerne vælge et system, som spil er lavet til, selvom systemet ikke var en dedikeret videospilkonsol. Jeg føler, at det at være i stand til at køre spil på emulatoren ville være meget motiverende for de studerende.

Jeg er helhjertet enig her. Meget af succesen med Andre LaMothe s eksperiment- og læringssystemer er baseret på den største evne til at lave spil.

For eksempel ser jeg lige nu på NES, men det føles stadig lidt kompliceret, især PPU. Er der enklere muligheder?

Det bliver svært, da de grundlæggende krav modsiger hinanden. Kun vellykkede konsoller / computere fik et stort udvalg af spil, men disse er også sådan, at de har en mere kompleks hardwarestruktur, der giver gode spil.

Lad os kontrollere nogle kendte systemer. Jeg vil gerne adskille dem i “enkle” og “komplekse” systemer langs kompleksiteten af deres videologik (* 1)

Simple Systems

I første iteration er dette alle systemer uden en dedikeret VDC / CRTC.

• Atari VCS – til sidst det ultimative system, der skal bruges til at lære montør, arbejde på et ekstremt grundlæggende niveau uden imellem og ikke meget at tage sig af. Samtidig er det “s navnebror til” racing the beam “-udtrykket.

  Når det er sagt, kan det stadig være et system at se efter, da de tidsafhængige dele er veldefinerede og (sammenlignet med enhver anden video) ekstremt simpelt og let at efterligne – bortset fra at det ikke er førsteårs ting. Det er også ekstremt veldokumenteret på almindeligt tilgængelige kilder.

• Commodore PET – Et ret simpelt system, især siden hele videodelen kan emuleres ganske abstrakt, men VIAerne skal i det mindste delvist emuleres. Vigtigst, det indeholder kun to timingkilder (ved siden af uret).

  Et godt plus for PET (og opfølgning) er den gode dokumentation (også på grund af sin enkelhed). Selvom den indeholder en CRTC, har næsten intet spil (eller anden software) overhovedet brugt omprogrammering af den, hvilket gør en måde enkel og en ufuldstændig (abstrakt) emulering mulig.

  På bagsiden er der kun et ret lille antal spil, og de fleste af dem er skrevet i BASIC, hvilket muligvis kræver en vis undersøgelse for at finde mængden af abstraktion vs. detaljer i emulering.

• Apple II – Igen et utroligt veldokumenteret system med masser af software. Meget af det monteringsbaseret. Mens hardwaren er fuldt dokumenteret og bygget udelukkende fra TTL, er den ikke meget enkel, og da nogle spil i høj grad er afhængige af quirks og tællesløjfer for nøjagtig timing, kan emulering blive langt mere kompliceret end antaget ved første øjekast.

  Et plus for dig kan være, at Apple II var ganske populær i Brasilien (godt dengang).

• TRS-80 – Også her videologikken er opbygget fra TTL, men langt mere enkel end på Apple. Lignende anden I / O er ret enkel. På den negative side er der igen et ret lille antal spil.

Indtil videre kan de virkelige gamle, men også nogle senere systemer klassificeres som enkle:

• Sinclair Spectrum – Mens logikken giver nogle få tricks, fløjter klokker &, men det er et lige fremad flisebelagt bitmapdesign. Indtil videre er chancerne gode for en emulering, bortset fra, som sædvanligt, stod spil meget på timing, noget der komplicerede emulering igen.

  Såvel som med Apple II, hvor der er ganske mange kloner i Brasilien .

• En lignende sag kan gøres for ORIC-familien

• Atari ST – Det kan være en overraskelse fra i dag synspunkt, men Atari ST havde ikke nogen sofistikeret videohardware. Blot 3 grafikopløsninger og en 9 bit CLUT til op til 16 samtidige farver. Et par synkroniseringspunkter og en enkelt timer. Plus en mere moderne CPU og en dedikeret lydchip. Lyder som en kamp lavet i himlen, hvis, ja, hvis det ikke ville være for programmørerne af spil igen. Også her indebar software en hel overflod af tricks til at skabe fantastiske spil (* 2).

En første konklusion for “enkle” systemer er, at selvom hardwaren måske er mindre kompleks, gik software meget langt for at overvinde dette. Som en konsekvens kan siges at mindre komplekse systemer ikke er nødvendige for at gøre en emulering mindre kompleks, da der ikke skal emuleres mere forskellig hardware, men den enkle hardware skal følges meget tæt timing for at få eksisterende spilkode til at køre.

Komplekse systemer

Disse er generelt alle systemer med en sofistikeret VDC

• 9918 ff .- Dette handler ikke så meget om et enkelt system, men til sidst den mest almindelige brugte VDC (TI kaldte det VDP). Mens den blev udtænkt til TI 99/4, solgte TI den til alle der var interesserede. Det resulterede i flertallet af alle systemer (* 3) ved hjælp af en 9918 eller et af dens opfølgningsdesign (9928/38/58 / …).

  Spilkonsoller som Coleco Vision , Sega SG-1000 hele vejen til Master System en brønd som computere fra TI 99/4 eller Memotech MTX hele vejen til hele MSX maskiner brugte denne familie.

  Det lyder godt, ikke sandt? Der er helt sikkert mange spil, der skal bruges. Yderligere hjælper en sådan VDP med at forenkle emulering, da den giver en klar adskillelse mellem CPU og skærm og begrænser, hvilke “tricks” et spil kan bruge til, hvad VDP tilbyder, hvilket igen er klart defineret. Og igen, det er den eksisterende software, der gør emulering vanskelig, da naturligvis programmører selvfølgelig brugte timing-tricks til at manipulere skærmen på det rigtige tidspunkt. Nævnede nogen “Racing the Beam”?

• Commodore VC20, C64, C16 osv. – Det samme gælder for alle Commodores hjemmecomputere. Mens de adskiller sig i kompleksitet ved at have sprites eller ej, tilbyde timere eller ej og lyd eller ej, er det grundlæggende problemet er det samme som i 9918-familien: Software, der bruger bestemte tidssituationer til at skabe spileffekter.

• 6847 Systems – Tandy CoCo, Matra Alice og lignende har det samme problem.

Jeg kunne fortsætte med spilsystemer som NES eller MegaDrive, men jeg slutter listen her, da princippet skal være klart nu: Mens nogle systemer kan sømme som mere kompliceret at blive efterlignet, er det virkelige problem ikke kompleksiteten af videohardware, men når en programmør “forbedrer” hvad kan der gøres ved smart programmering (* 4). Så det virkelige problem for dit projekt er ikke (så meget) hardware (* 5), da det er softwaren, især de tricks og værktøjer, der bruges i ægte eksisterende spil .

Det er især dårligt, da du vil bruge (som jeg læser det) eksisterende spil som motivation. Der vil ikke være mange der kører på en mindre hård realtidsemulering.

Hvis du reducerer denne afhængighed, reduceres antallet af spil, der kører korrekt. At reducere det til et niveau, der gør det muligt at håndtere det i et tidsbegrænset forløb, gør det næsten umuligt at finde passende spil.

Konklusion: At finde højre afvejning er en måde, men en, der vil tage betydelig forskning, mens den stadig begrænser anvendeligheden.

---

Nu er det måske muligt at angribe dette fra en lidt anden vinkel. Lad os prøve nogle:

• Brug af eksisterende gammel hardware:

  Selvom dette er bevist (* 6) fungerer, tilbyder den højeste kompatibilitet og brugervenlighed på grund af åbne udviklingsmiljøer, kan det gå glip af “build” -appellen til EE-studerende.

• Brug eksisterende undervisningsspilsystemer:

  Systemer som Andre LaMothe “s XGS er gode værktøjer til at dykke ned i detaljeret hardwareopbygning og programmering. Sikker på, at der kræves noget lodning (der er klar bygning tilgængelig), de er næsten komplette softwaredefinerede systemer, dokumenteret igennem og tilbyder et stort bibliotek med spil. For ikke at nævne hans bøger om spilprogrammering.

  En stor bonus er, at studerende muligvis kan tage systemet hjem og spille, selv efter kurset er afsluttet.

• Byg dit eget enkle system:

  Tag en klassisk CPU (f.eks. 6502), noget RAM, FLASH og en VIA plus en FPGA til at implementere en meget grundlæggende CRTC og færdig. Studerende lodder det, kan lære om komponenterne og deres interaktion, herunder FPGA-brug (hvilket muligvis er et must alligevel i dag) og derefter køre deres software på ægte hardware. Selv med et lille antal skal det være muligt at producere et sådant bord omkring 50 Euro eller mindre. Ligesom XGS-ideen fungerer det, når kurset er afsluttet – inklusive følelsen af ejerskab som deres system.

  Selvfølgelig skal studerende skrive deres egne spil, men enkle spil kan gøres på ganske kort tid – for ikke at nævne, at opfølgningskurser lige så godt kan bruge spil, som den tidligere klasse skrev.

• Lav en emulering af “dit eget” system

  Meget som før, bortset fra at alt er virtuelt. Det fik fordelen ved at være en brønd defineret og lukker system, især et hvor der ikke er nogen begrænsninger på grund af en mindre “perfekt” emulering – Emuleringen er perfekt pr. definition, og alle dens egenskaber er den, systemet har. Ulempen er igen softwaredelen.

• Brug “soft” hardware:

  Der er et projekt af Neil Franklin, der skaber et antal generaliserede systemkomponenter, ligesom klassiske computere havde, men ved hjælp af mikrokontroller i stedet for dedikerede chips. Det kombinerer emulering med ægte hardware. Mens komponenter stadig er udviklet som emulering, er disse beregnet til at køre i en mikrocontroller og bruges omtrent som “rigtige” chips. Et system kan oprettes ved hjælp af et SoftCPU-modul, der emulerer for eksempel en 6502 med noget RAM og ROM, kombineret med en SoftVGA, der leverer en terminal som videointerface og et SoftPS2-emulerende tastatur og mus. Alle er forbundet via en parallel eller seriel (SPI) bus, der tillader tilføjelse af andre komponenter, der også kan præsenteres for emuleringen.

  Udover at være alt om emulering, har den en begrænset mængde hardware, der kan gøres på et brødbræt (Alligevel er det aldrig for tidligt at begynde at lodde), det viser også en ganske typisk opgave med nutidens teknik – udskiftning af traditionel logik med mikrocontrollere – i praktisk brug.

  resultatet er et system, der tilbyder touch og følelse af en ægte (gammel) computer, mens den bygges med moderne hardware, der kører parallelle emuleringer.

• Brug af en konfigurerbar emulator:

  Nej, dette handler ikke om MAME eller ens, men om en emulatorramme skrevet i JavaScript, der håndterer de generiske dele (inklusive timing), hvor dine elever vil tilføje deres emuleringer (hvilket var et mål, var det ikke?) for at danne et helt system. Da JS leveres som kilde, kan selv selve Framework ændres.

  Afhængigt af kvaliteten af hver emulering kan dette muligvis bruges til alt fra et simpelt demonstrationssystem til en fuldstændig rekreation i 1980erne. computer.

Så måske nogle af ovenstående variationer kan være en god start?

---

* 1 – Jeg vil kun fokusere på video (og CPU) for at holde det enkelt. Også video alene fungerer allerede godt for at udrydde komplette systemer. Lyd tilføjer en anden dimension og kan komplicere den langt uden for dette.

* 2 – Se bare på Xenon. En banebrydende lodret scroller med flere skiftende lag, mange animerede objekter, som alle kører super glat i software. Faktisk var det så finjusteret, at det at porte det til det (normalt) mere dygtige Amiga (grafikmæssigt) tog lang tid og resulterede i et noget mindre spil.

* 3 – Systemer designet ikke nødvendigt solgte enheder. Derefter er der nogle spilkonsoller, der mere end bare lykkes, så det kan endda få flertallet i antal.

* 4 – Blogposterne til hovedudvikleren af Glide64 renderer-plugin til N64-emulatorer har skrevet en serie med flere dele ( Intro , P .1 , P.2 , P.3 ) af blogindlæg om de forhindringer, han var nødt til at klatre for at få videoemuleringsdelen til at fungere – alle handler ikke om kompleksiteten ved at emulere hardwaren, men alle måder, CPUen ændrede og finjusterede output ved siden af videologikken. Dette er endnu mere bemærkelsesværdigt i betragtning af at N64 allerede er et temmelig absakt og lukket system.

* 5 – Faktisk vil jeg betragte mere kompleks videohardware som en god lektion for EE-studerende, da det godt viser hvad kan gøres med et par gate i stedet for bunker af software – endnu mere, da de er ved at gøre hardware senere, er det ikke?

* 6 – Stefan Höltgen ved FU Berlin bruger f.eks. gamle spilsystemer i sine klasser for at introducere (ikke-EE) studerende til ægte hardware og ægte programmering og deres implikationer for hverdagsopgaver (og spil).

Kommentarer

• @Tommy Nå, jeg vil meget gerne undgå dette, da der ikke er noget let svar. Det vigtigste her kan være, at mens Z80 er noget ” quirky “, 68k er alt andet end enkel. Med alle udvidelsesordene (op til CPU32) kan en enkelt instruktion have op til 11 ord (22 byte), og afkodning er et seriøst rod. Så igen, det hele afhænger af hvordan emulatoren er sammensat. Z80 er en ret lige fremad 8080, nem at efterligne, med et par modifikatorer, som let kan håndteres. For 68k, selv kun den originale, vil det være langt mere arbejde.
• ” opgave, der passer til nybegyndere i så begrænset tid. ” Han sagde, at dette er 3. års studerende, ikke førsteårsstuderende, og de ‘ har allerede gennemført flere forudsætninger.
• @ wizzwizz4 Nå, uanset hvad vores personlige mening er, er JS den juridiske arving til BASIC. Seriøs og på alle måder! Bare tænk over det.Det kører ikke kun n ved siden af enhver faktisk computer, det ‘ er endda installeret som standard, og der er næsten ingen måde at slippe af med det uden at miste meget funktionalitet. Endnu mere, bare tænk på, hvor meget dårlig og utrolig langsom software der er skrevet i JS – det perfekte bevis, er det ikke ‘?
• @Raffzahn Det ‘ er helt anderledes For det første havde BASIC flere uforenelige implementeringer … Ohhh! Det er efterfølgeren til BASIC!
• De ‘ er stadig ikke førsteårsstuderende, der er førsteårsstuderende. Og jeg synes, du skal give OPen fordelen ved tvivlen om, at han ikke ‘ ikke tildeler projektet, hvis de studerende ikke ‘ t har den krævede baggrund.

Der er nogle gode ideer indtil videre.

Men noget at overveje.

Hvis du gør noget som en CP / M-maskine, er de virkelig ret grundlæggende og enkle, især da alt er isoleret af ikke kun BIOS, men også IN / OUT-naturen af 8080 / Z80-familien.

Det forekommer mig ikke uhensigtsmæssigt at have en CP / M-maskine til at være målet for det første semester. (Jeg kender ikke din pensum)

Men for eksempel behøver en grundlæggende CP / M-maskine ikke cyklusnøjagtighed, den behøver ikke afbrydelser, det mest komplicerede, den skal gøre, er at polle tastaturet for at se, om der er trykket på en tast. (I modsætning til overvågning af keydown og keyup eller noget andet.)

Derefter, i andet semester, kan du tilføje kravene såsom grænseflade til en grafikchip. Eksemplet ovenfor af SG-1000 kunne let være en CP / M-maskine i det første semester og derefter let omdannes til SG-1000 i det andet (da du har fået Z80-delen færdig i det første semester) .

Endelig synes jeg, det kræver din klasse at have et acceptprogram, som eleverne kan køre for at verificere deres CPU. Få ting mere spændende end fejlretning af en dårlig CPU, især med maskinsprog, som du måske ikke er fortrolig med .

6502-samfundet har testprogrammer, der kan kontrollere, at en CPU udfører alle instruktionerne korrekt, jeg er ikke sikker på, hvad der er til rådighed for de andre CPUer.

Og hvis det er enhver trøst i omfanget, jeg skrev både en simulator og en tilhørende samler af og på over en 2 ugers juleferie, hvis det giver dig nogen hjælp til, hvor store de faktiske projekter er. Grundlæggende CPUer er ret enkle.

Kommentarer

• På Z80 leverer FUSE test, men ikke alle er generiske eller nødvendigvis korrekte med hensyn til nøjagtig cyklus timing; de ‘ er også i et ad hoc tekstformat, men jeg ‘ har transkriberet dem til JSON: github.com/TomHarte/CLK/tree/master/OSBindings/Mac/… – brug tests.in.json til at indstille starttilstande og find ud af, hvordan længe skal du køre for, så tests.expected.json for at kontrollere resultaterne. Der ‘ findes også zexall og zexdoc, oprindeligt CP / M-filer, men bredt tilpasset og meget langsom. At passere førstnævnte kræver, at en masse udokumenterede ting skal være korrekte, og at passere sidstnævnte ikke ‘ t.
• … og det eneste, jeg ‘ der nogensinde er fundet til 6809, forudsat at nogen tænkte at foreslå en Vectrex eller Coco / Dragon, er indeholdt i en bredere Williams arkadesmags testpakke på seanriddle.com/wetsold.html . I 6502 er jeg meget ombord med testene fra Klaus Dormann, Wolfgang Lorenz og AllSuiteA, som alle synes at være meget mere fremtrædende end Z80- eller 6809-testene.
• @Tommy Så vidt Jeg er ‘ opmærksom på, at hver af Fuse ‘ -test er cyklusnøjagtige. Indsend fejl, hvis de ‘ ikke er 🙂
• @PhilipKendall se min e-mail af 29/5/2017 for at fuse-emulator-devel re: DJNZ og om offset læses på en endelig iteration. Konklusion fra Alan Cox om, hvorvidt FUSE ‘ s testede adfærd er korrekt, var at den ‘ s ” åben for fortolkning ” baseret på de tilgængelige kilder. Så jeg mente, at ” ikke nødvendigvis var korrekt ” var fair. Jeg burde sandsynligvis have været klar: Jeg fandt kun en håndfuld afvigelser i dit team ‘ s fortolkning af bevismateriale og min egen. Undskyld for dårlig form på det.
• @Tommy – ” Konklusion fra Alan Cox om, hvorvidt FUSE ‘ er testet adfærd er korrekt var, at den ‘ s ” åben for fortolkning ” baseret på den tilgængelige kilder ” …mens jeg har stor respekt for meget af det, Alan gør, er det ‘ ret nemt at kontrollere, om den testede adfærd er den samme som en faktisk Z80 CPU (især for CMOS-versioner der kan køres på breadboard med lave urhastigheder for at opsætte detaljerede tests meget enkelt), så dette er bestemt et tilfælde, hvor hvis han mener, at der ‘ er noget galt, skulle han være i stand til at demonstrere det meget let.

Kan jeg foreslå SG-1000 ?

Systemet er lidt mere end en gruppering af tre fra hyldechipsene – Z80, TMS9928A til grafik og SN76489 til lyd med controllerne som dumme grupper af NO (normalt åbne) switche.

I software eller hardware kan du simulere eller efterligne enhver del af dette isoleret eller alt sammen for at producere det komplette system.

systemet bruger simple ikke-bankomskiftede ROMer til sine spil, og de bruges normalt y stole ikke på nogen tricks såsom afbrydelser i midten af skærmen eller cykeltælling for at få deres effekter. Bare et enkelt flisekort og et antal sprites på toppen. Jeg foreslår, at dette er meget mere ligetil end et system, der indeholder mange interagerende interne komponenter og intelligente patroner som NES.

Du burde give dine egne spil til at efterligne i stedet for at distribuere ulicenseret naturligvis copyright-beskyttet materiale.

Kommentarer

• … og for ordens skyld er ColecoVision nøjagtig den samme samling af komponenter med forskellige forbindelser logik og meget lidt mere komplicerede joypads. Så en SG-1000-emulator er normalt let at udvide for at understøtte begge.
• Også bemærkelsesværdigt, at 9918 er en kompleks chip med sprites, komplekse modi og data, som han ikke gjorde ‘ vil ikke bruge. Er det ikke ‘?

Et simpelt, ligefrem computer som ZX Spectrum lyder fornuftigt – Men der er simpelthen for mange gode emulatorer rundt for at gøre dette til en nyttig mulighed. Jeg synes også, at 6502 er lettere at efterligne.

Så en mulig mulighed kan være Oric-1 eller Atmos by Tangerine-systemer , der brugte en 6502 hukommelse uden bank, ingen brugerdefinerede chips undtagen simpel video og en relativt ligefrem rammebuffer. Det er langtfra ikke så kendt som Spectrum, men der er stadig software (spil) til rådighed til at bringe nogle enkle kompatibilitetstest med (jeg tror, en eller anden “følelse af præstation” er ekstremt vigtig for studerende). Der er et antal emulatorer, der allerede er tilgængelige for Atmos (tre, efter min viden), men deres antal er begrænset, hvilket gør det let at finde ud af, om nogen snydte og simpelthen kopierede koden.

Ingen af Oric-spil var så sofistikerede efter min viden, at du ville have brug for en 100% cyklusnøjagtig emulering for at køre spillene,

Kommentarer

• I ‘ d hævder, at Oric-arkitekturen afskrækker rasterracing ved ikke at have en sidekanal med videostyringsregistre og ikke er indstillet, så racing muligvis kan øge din farveopløsning (i modsætning til et spektrum). Hvis det dog kun havde to HIRES-buffere, sagde jeg ‘ d det mere fortroligt. Er du enig i det?
• @Tommy I ‘ Jeg er ikke så fortrolig med Oric-videokredsløbet. Hvad jeg under alle omstændigheder vil sige er, at Oric havde en så kort levetid og en så begrænset brugerbase, at sofistikerede teknikker til at finjustere videoen som vi kender fra ZX Spectrum ikke var ‘ t udviklet (i det mindste ikke i computerens aktive levetid, der ‘ et antal interessante demoer her demozoo.org/platforms/ 49 )
• Åh, så giver jeg ‘ bedre ræsonnement: Oric-videochippen har en modal tilstand, inklusive tekst eller grafik, men ingen udsatte registre. Alt er indstillet af kontrolbyte i videostrømmen – inklusive forgrunds- og baggrundsattributter. Folk har en tendens til at klage over det, fordi det betyder, at hvis du vil have gapløs grafik, er du ‘ begrænset til fire farver pr. Linje, hvoraf to er de bitvise komplementerer af de to andre. Nogle af de moderne spil ser dog stadig rigtig godt ud – f.eks. Stormlord youtube.com/watch?v=QSDy-BC580M
• @Tommy De serielle attributter gør programmeringen lidt mere vanskelig, jeg ‘ d gætte, men mængden af attribut sammenstød er endnu bedre end på ZX Spectrum, regner jeg med.
• Xenon 1 har brug for en cyklus nøjagtig, ellers låser den sig, når skibet eksploderer (ansvarsfraskrivelse: Jeg skrev en oric-emulator til amigaen kaldet amoric og snublede ind i dette emne, men kun om netop dette spil)

Baseret på dine kriterier og behovet for at holde projektet interessant for dine studerende, vil jeg anbefale seriøst overvejet Vectrex Arcade System, som blev solgt af Milton Bradley i begyndelsen af 1980erne.

Fordi Vectrex er unik ved at bruge en vektorvisning i stedet for en rastervisning, gør den ikke kræver, at kompliceret videohardware emuleres. Skærmen administreres af CPUen, og selve skærmen er enkel at efterligne på et moderne system og med god ydeevne.

Udover at emulere vektordisplayet, er CPUen ( Motorola 6809) og I / O-chippen (MOS 6522) repræsenterer ikke for slim h af en udfordring, da de er enkle 8-bit dele, der er meget veldokumenterede.

Hukommelsesmodellen er også meget enkel uden bankordninger, som jeg ikke er opmærksom på. Der er en almindelig PSG-lydchip i Vectrex, men efterligning af den kan betragtes som “Ekstra kredit”.

I modsætning til andre enkle spilkonsoller i begyndelsen af 1980erne har Vectrex-spillene holdt sig ret godt, givet dets evne til at gengive glat monokrom grafik inklusive 3D-trådramme. Dette fremgår yderligere af populariteten af den moderne “hjemmebrygg” -udvikling, hvor udviklere fortsætter med at skabe nye Vectrex-spil.

En sidste fordel for Vectrex er, at det originale system-ROM frit kan distribueres.

Kommentarer

• Bortset fra at vectrex også fots godt med ‘ Racing the Beam ‘ cathegory, gør det ikke ‘ det?
• @Raffzahn, som jeg forstår det, styrer Vectrex CPU elektronstrålen – nøjagtigt det modsatte af en “, der kører strålen “, hvor software skal foretage nøjagtigt ændrede tilstandsændringer til holde øje med et eksternt tidsbestemt raster-scanningsdisplay.
• @Mark Det ‘ er det samme med VCS. Også her styres strålen af CPUen. Uden at CPUen har adgang til WSYNC hver linje, og inden linjen er færdig, vil skærmen falde. Og så vidt jeg forstår OP, handler det ‘ om ikke at genskabe et system med strenge timingkrav – som er essentielle for Vectrex.
• @Raffzahn: CPUen i VCS styrer lodret, men det styrer ikke vandret. Det ‘ er ikke usædvanligt, at et spil udsender snesevis eller endda hundreder af scanningslinjer uden en mellemliggende WSYNC. I fravær af en WSYNC vil strålen være i den samme vandrette position hver 76. cyklus. Opbevaring af WSYNC er ofte den nemmeste måde at vente på, at strålen når til højre side af det viste område, men det ‘ er næppe den eneste måde. En programmør, der var så tilbøjelig, kunne udnytte de indviklede detaljer ved sprite-bevægelse og adfærd til at skrive et spil, der overhovedet aldrig brugte WSYNC.
• Um, folkens, vi taler om en emulator her. Der vil ikke være et problem med, at fosforene falmer, mens den emulerede CPU tager for lang tid at tegne den næste ramme. Der er ingen ” stråle ” og der er bestemt ingen grund til, at emulatoren skulle have brug for at ” race ” da emulatorens display forbliver ganske statisk, så længe det er nødvendigt mellem rammer.

Oprettelse af en emulator fra bunden er relativt stor opgave, især for uerfarne studerende og kan vise sig at være problematisk. Så du skal virkelig være forsigtig med, hvilken platform du skal efterligne, og hvilken info du vil dele / bruge. For mig er det bedste valg en ZX 48K platform da jeg voksede på den og er fortrolig med dens indre funktion, så svaret vil være forudindtaget af det … Men vi skal huske på, at studerende i dag normalt ikke så / brugte / vidste det så meget som vi gør … Hvad du skal opnå er:

1. korrekt CPU-iset-emulering

   selvom der er masser af instruktionssæt-dokumenter derude Du skal være forsigtig, for eksempel på Z80 indeholder 99,99% af dem fejl. Så du skal vælge en testet reference iset for dem, du er nu korrekt (eller i det mindste basisk funktionel).

   For eksempel er her min Z80-iset, der passerer ZEXAL med 100% succes:

   • min Zilog Z80A komplet instruktions sæt med maskincyklustiming

   Z80-platformen har en stor fordel, og det er, at der er omfattende testere for det som ZEXALL Træner , som kan hjælpe med at debugge emulatoren meget.

   Jeg tror der, hvor også versioner til i8080 men jeg kender ikke nogen sådanne testere til anden CPU-familie.

2. Timing

   godt til grundlæggende emulering er uretics-metoden (eller throttling) nok, som er velkendt og brugt … Jeg ser ikke noget problem her. I dag har computere en relativt god opløsning til timing (på pc: RDTSC, på Windows PerformanceCounter, …).

   Den grundlæggende emulator kan ignorere den emulerede platforms INDHOLD, men pas på, at nogle OS / spil / apps kunne gøres ubrugelig, hvis de ikke efterlignes korrekt. Dette gælder ikke kun for demoer. Den sædvanlige timing på gamle computere stammer fra nogle afbrydelser (normalt videoopdatering) og et begrænset antal cyklusser, hvor de er i stand til at udføre inden den. Men med påstanden kan antallet af instruktioner, der udføres på samme tid, være meget forskelligt, og nogle programmer kan løbe over og skade dem selv eller fryse. INDHOLDET er den sværeste ting at implementere med clock-tics, så du bør undgå det for enhver pris … På den anden side med MC-niveau-timings er det virkelig nemt og bare et par linjer med kode. li>

   Lyd

   dette er platformafhængigt problem, og du skal vælge den API, der bruges til lydindgang / -udgang korrekt. For eksempel på windows er den eneste anvendelige mulighed WAvEIN / WAVEOUT på grund af lav latenstid og nem brug. DirectX er ubrugelig (var i det mindste på det tidspunkt, hvor jeg prøvede at bruge den til en sådan opgave) på grund af HØJ ventetid og ikke fungerede tilbagekald.

   Jeg ville bruge bufferet tilgang i stedet for direkte højttalerkørsel, så din emulering kan sprænge udførelsestid i stedet for MC-niveau korrekt udførelse (hvilket jeg alligevel gør, men jeg tvivler på, at studerende ville være i stand til at gøre det i den aktuelle tid).

3. Video

   Denne er også platformafhængig. .. og du skal bruge API, som dine studerende kender. Selv strålesporing er relativt let at implementere med simpel bitmap … På computere som ZX har Scanline-rækkefølgen en særlig betydning og kan være meget distraherende for nybegynderkodere, så det er bedre at bruge oversættelses-LUT-tabeller, der konverterer mellem adresse og y-koordinering frem og tilbage.

   De fleste ældre platforme brugte 50Hz / 60Hz opdateringshastighed og relativt lille opløsning, så computere i dag, selv med ikke godt optimeret emulering, skal stadig være hurtige nok til det. Hvis ikke, er det også en mulighed at springe over rammer …

4. andet HW og periferiudstyr

   Det absolutte minimum er RAM / ROM-hukommelse og tastatur. Hukommelse er normalt meget let bare statisk array og eller nogle sider, der skifter side … Tastaturet kan efterlignes ved at indstille I / O i henhold til de taster, der trykkes på. I / O kan også kortlægges hukommelse til nogle array ligesom hukommelse. Fældning af ISR-rutine er også en mulighed, men det gør tastaturet ubrugeligt for brugerdefinerede nøglehåndterere.

   Jeg gider ikke med FDC, AY osv. Perifere enheder, da emulatoren skal holdes så enkel som mulig. Men hvis du er heldig, kan der være nogle studerende, der vil være langt foran andre med dette projekt. For dem kan du foreslå at implementere spændende funktioner som FDC, DMA, endda ægte lydkortlyd (til ægte bånd eller andre lydafspillere), som muliggør meget gode funktioner for eksempel se:

   • Z8410 DMA-chip som GPU?

5. Filer

   Jeg ville gå efter Z80 / SNA-filformater ved start. At bruge TAP / TZX er rart, men fra starten af ville emulatoren være ret buggy, hvorfor indlæsningsrutiner muligvis ikke fungerer korrekt, hvilket gør brug og fejlretning meget hårdt.

6. ROM

   dette er den mest problematiske del, da mange platform-ROMer stadig ikke er gratis, og ved at udpakke / downloade / bruge dem til emulering kan du risikere juridiske problemer.

   Fra nogle kommentarer her ser det ud til, at ZX ROMer er offentlige domæner nu … og der er også kommenterede ROM pri nts derude, hvilket gør det meget nemmere at fejle de første trin i emulatoren (når intet endnu fungerer).

   Men du bør altid overveje Emulering og juridiske ting især hvis emulatorerne placeres et eller andet sted på internettet

Her er nogle relaterede QA-links af mig:

• Sådan får du CPU og andre hardwarespecifikationer til emulatorudvikling
• Skrivning af en grafisk Z80 emulator i C eller C ++ Jeg anbefaler på det kraftigste at læse denne (specielt for dine studerende) vil spare dem for meget tid og nerver
• Hvad er den korrekte implementering af hardwareemulering?

Leder du efter en system, der ikke er blevet emuleret meget? Jeg foreslår at forblive inden for 8-bit computere (eller tidlige enkle 16/32 bit-stykker), ZX Spectrum 48k er et så relativt simpelt system – meget veldokumenteret, ingen sprites, ingen lydchip, ingen RAM-banker, enkel I / O, si Mple grafik (dog med et underligt layout), ingen cyklus perfekt emulering krævet, velkendt CPU, let kassettehåndtering (kunne gøres endnu lettere af ROM-fælder). Der er tons spil, mange af dem med tilladelig licensering.

Ulempen: der er en enorm mængde tilgængelige emulatorer, mange selv retrokategorien, og mange med kildekode tilgængelig, så faren for at snyde og kopiere anden kode er stor.

Og selvfølgelig vil arbejde på en emulator af et tidligere ikke emuleret system give yderligere fordele ved følelsen af at blive udført.

Kommentarer

• Jeg havde det samme instinkt, men ville udvide ved at foreslå, at SNA og Z80 og veldefinerede nok snapshotformater, som du har brug for ‘ t engang bekymre dig om båndemuleringen. Og lad os ‘ være ærlige, TZX er lidt af en miasma på dette tidspunkt.
• Jeg tror, at Spectrum ROM nu er i det offentlige domæne, hvilket kan hjælpe (eller gøre tingene for lette)
• ZX Spectrum er et godt eksempel på simpel hardware, men også en af ganske komplekse cyklustælling (Racing the Beam) programmering for at få brugbare spileffekter.
• @Tommy Åh, jeg vil aldrig foreslå ZX80 / 81 af samme grund. Og selvom det ikke er en ægte Spectrum buff, har jeg set en god timingafhængig kode til det. De fleste prominet skærmmanipulationer efter den del er blevet vist, men før den kører en gang rundt. Det ‘ er et meget simpelt problem, der findes på en hel masse systemer. Intet stort problem, men tidsafhængig. For eksempel enkle emuleringsordninger, der kun reducerer hastigheden på et billedniveau, vil producere crap på hurtigere emuleringsværter … og så videre.
• @Stormcloud Spectrum ROM er ikke i det offentlige domæne, selvom tilladelse har været tildelt til at distribuere det til brug med emulatorer. ZX80 og ZX81 ROMerne er frigivet under GPL.

Må jeg foreslå at se på nogle tidlige arkadespil? Specifikt disse to 8080 / Z80-platforme:

• Midway 8080 – Udviklet i 1975 og styrker Space Invaders . Bruger en 256x224x1 bit sort-hvid rammebuffer i RAM.

• VIC Dual – Sega / Gremlin “s platform designet i 1977 – det mest kendte spil er Carnival . Videoen er en 32×28 række med 8×8 tegn (alle i RAM) og kan understøtte en simpel farvepalet, kortlagt til en PROM.

Disse er meget enkle at efterligne, når du først får Z80-emuleringen til at fungere. Der er ingen sjove scanline-tricks eller underlige CPU-ventetilstande. kontroller er tilgængelige via bitmappede I / O-porte.

Du kan spille med disse platforme interaktivt på http://8bitworkshop.com/ (Fuld offentliggørelse: Jeg driver dette websted og er forfatter til de bøger, der er linket på webstedet, der beskriver disse platforme)

Apple] [er også et godt valg til en 6502-baseret platform, skønt videoundersystemet er mere kompliceret end i de to arkadeplatforme.

Kommentarer

• Til hvad det ‘ er det værd, jeg synes, Space Invaders er et inspireret forslag. Hvis hukommelsen tjener den ‘ er bare en 8080 med en 1bpp bitmappet skærm, en eller anden port IO til kontrolelementerne, intet forsøg på at køre raster, lyd der bare er af formen ” udløserstøj X nu “, meget afslappede nøjagtighedskrav, og det producerer et spil, som de stadig lejlighedsvis prøver at sælge nu. Det ‘ er kun det lovlighedsproblem, der kan give pause, selvom jeg ‘ altid er uklar på akademiske undtagelser.
• At ‘ er stort set rigtigt, der er ‘ også en ekstern chip, der hjælper med 8080 ‘ mangler en tøndeomskifter. Der skal ikke være ‘ noget legalitetsproblem, der emulerer hardwaren (der ‘ er ikke ophavsretligt beskyttet BIOS eller anden kode) og det ‘ er ret let at skrive dit eget spil, fx: 8bitworkshop.com/v3.2.0/?platform=mw8080bw& file = game2.c

PET eller TRS80 fungerer muligvis godt. Enkel hardware med tekst på skærmen, så de kunne emuleres med lige tekst. Ouput tilføjede oprindeligt kode til deres ulige tegnsæt senere og sandsynligvis ikke meget i vejen for nøjagtig cyklustællingskode.

Bonuside efter, hvis du gå efter en PET ved at tilføje C64-understøttelse ville give grafik.

6502 er sandsynligvis lettere at efterligne.

Den endelige tanke kan være Ohio Scientific Superboard II eller i den britiske inkarnation UK101, da jeg ikke tror, det har omprogrammerbar videohardware.

Kommentarer

• Ja, alle tre (PET, TRS, Superboard (jeg glemte helt om den senere)) er gode enkle maskiner og gode til emuleringer. Men mangler også et godt udvalg af klar til brug spil. For ikke at nævne farve, og som folk kan forvente i dag.

Digital PDP-8 er en meget enkel arkitektur, der kan være let at skrive en emulator til. Nogle af grundene til dette inkluderer:

• Kun 8 grundlæggende instruktioner
• Ingen videointerface osv. At efterligne, kun terminal I / O
• Intet behov for cyklusnøjagtighed, den aktuelle serie af maskiner i sig selv garanterede ikke den samme adfærd på tværs af de forskellige implementeringer
• Kan starte med en simpel opsætning (f.eks. en 4Kword-maskine, der kører FOCAL-69) og gradvist gøre emulatoren mere kompleks (f.eks. en 32Kword-maskine med udvidet aritmetik, der kører OS / 8 fra en RK05-disk)
• Masser af manualer tilgængelige online
• MAINDEC-diagnostikken og deres instruktioner er tilgængelige online, som kan bruges til at teste, at emuleringen fungerer korrekt

Dette dækker muligvis ikke alle dine krav, f.eks. hukommelseskortet I / O, men det inkluderer bestemt ting som instruktionsafkodning og adresseringstilstande. af dokumentationen går helt ned til det grundlæggende hardwareniveau, der kan være passende for et EE-kursus.

Kommentarer

• Et interessant punkt er, at de fleste af de ovennævnte systemer har enten Z80- eller 6502-CPUer, som begge mangler noget med hensyn til deres understøttede adresseringstilstande. Hvis dækning af adresseringstilstande er vigtig, har PDP-8 et meget bedre valg af dem at demonstrere.
• For ” -spil ” aspekt af spørgsmålet, jeg tror, at Adventure stadig opretholdes / genopstår for PDP-arkitekturer (men kontroller det – jeg kan tage fejl).
• @TobySpeight You ‘ har ret, det opretholdes eller genopstår, men for PDP-10 , som er fuldstændig uforenelig med PDP-8.

ZX Spectrum-indstillingen er allerede fortalt: dens styrke er den fuldstændigt forenklede IO-hardware og det faktum, at mange eksisterende spil IKKE kræver præcis, cyklus -korrekt emulering af alle quirks med den eneste undtagelse af lyd (intet tæt på at korrigere lyd uden cyklusnøjagtig emulering af CPUen og korrekt nedsampling af den mellemliggende 1-bit lydstrøm produceret af CPUen).

Enhver anden mulighed for spilhardware som NES, G enesis og alle de lignende sprite-baserede maskiner er naturligvis ikke en mulighed, da der kræves masser af tid til at lære den komplekse hardware, udvikle måder at efterligne den, arbejde rundt om mangler i emuleringen osv. F.eks. endda “enkel” Super Mario spil på NES fungerer ikke, medmindre sprite-kollisionsbit i PPU er efterlignet korrekt.

De resterende muligheder IMHO er følgende:

1. tidlig teksttilstandsbaseret IBM PC
2. en af de eksisterende CP / M-maskiner
3. (ekskl. nogen “store” maskiner før “mikro” æra)

Nøglepunktet her er teksttilstandsvisning, det er ikke så svært at efterligne og meget enklere at vise på værtsmaskinen (endda ikke nødvendigt at vise pixelgrafik, arbejde med vinduesystem / SDL / osv.!).

Imidlertid er der stadig behov for en vis efterforskning for at indsamle ordentlige programmer til at arbejde med, herunder spil. Der er nogle teksttilstandsspil i CP / M, og de skal ligeledes være nogle til IBM PC.

Kommentarer

• Med en potentiel fordel ved en CP / M-maskine er, at der ‘ er bundet til at være mindst en, som kun 8080-emulering vil gøre?
• Dejligt, men så igen, der er ikke raly mange spil til IBM i teksttilstand, er der?
• @Raffzahn – der behøver kun at være en .
• @Jules Hehehe … ja rigtigt. Men så siger jeg ‘, at et minimum af 8080 gør tricket

Hvis det antages, at det er noget bidrag, er dette mine direkte noter til de maskiner, som jeg har skrevet emulatorer til, i omtrentlig start kronologisk rækkefølge, forhåbentlig for at tilbyde nogle farver på filformater osv.:

Atari 2600

Atari 2600s kendetegn er synergien mellem processor og grafikoutput; spil implementeres en realtidsfunktion, der leverer grafiske komponenter til videoudgangen, når rasteren kører. Så jeg synes, dette er et dårligt valg til det angivne formål – det virkelige hårde arbejde med at skrive en 2600-emulator er timing og samspil uden for mikroprocessoren.

Apple II

Relativ enkel hardware, men meget nuanceret, med flere grafiktilstande, og du skal gå mod undervisning i NTSC-video for at være i stand til afkode dets farveoutput. Efterligning af Disk II er også stort set et must, men det er lidt af en søgen i sig selv som de mest almindelige filformater forventer, at du leverer en Apple GCR-koder.

ZX80 / 81

Også sandsynligvis alt for kompliceret til det angivne formål, er den centrale indbegrebet at omlægge CPUens opdateringscyklus og et undersæt af instruktionshentninger for at scanne video. Hvis du valgte ikke at genimplementere den mekanisme som originalen, ender du kun med ROM-standardteksttilstand.

Commodore Vic-20

Dette er en almindelig bitmappet maskine med en simpel processor i 6502 og en anstændig mængde spil, hvoraf nogle blev leveret på patron, hvilket fritager dig for behovet for at efterligne et bånd eller et diskdrev. Den eneste flue i salven er dens 6522s; disse er kombinationstimer / Shifter / input / output chips med en hel masse quirks. Men en pæn fordel ved Vic-20 er, at den starter så langt som BASIC-prompten uden at fungere 6522s, og BASIC selv fungerer kun med timerne i 6522 implementeret , selv unøjagtigt.

Dens korte tid som markedsleder inden ankomsten af C64 begrænser også antallet af titler, der gør avanceret brug af hardwaren – der er samtidige eksempler på rasterracing såsom Imagic-titlerne , men de er i mindretal.

Filformaterne, som data bevares i, er et rod , men at begrænse dig selv til patronstøtte og være forsigtig med kun at bruge de titler, der blev leveret på patronen, skulle fjerne dette problem.

ZX Spectrum

Dækket andetsteds; Jeg synes et godt valg. Især hvis du holder dig til snapshot-filformaterne.

Oric 1 / Atmos

Dækket andetsteds; et anstændigt valg, men der er en anden af de irriterende 6522ere derinde. De fleste spil er tilgængelige på bånd, du bliver nødt til at understøtte alt det.

Acorn Electron

Bitmapped, en 6502 plus relativt simpel ekstern logik, men seks forskellige grafiktilstande og timing ville være besværet – omkostningerne ved hver cyklus er en funktion af det område, der er adgang til (ROM versus RAM), grafiktilstanden (40-kolonne versus 80-kolonne tilstande) og muligvis den aktuelle grafiske outputtilstand (80-søjletilstande blokerer RAM-adgang under pixelområdet; 40-søjletilstande ikke). Men du kan bare modellere det som en 1 MHz-maskine til de fleste spil og for det meste slippe af sted en liniecentreret version af grafikoutput.

Der er et lille antal spil tilgængelige på ROM, men heldigvis vil båndhardwaren for det meste tillade en meget lav kvalitetsemulering: det er af typen, der rejser en afbryde ved modtagelse af byte, med kun to titler, som jeg kan tænke på at gøre dybere introspektion end det.

Amstrad CPC

Sandsynligvis en for at undgå til det angivne formål – den har en 6845 CRTC, hvilket giver meget konfigurerbar grafikoutput og derfor mange titler, der kører rasteren. Diskbrug var også temmelig gennemgribende, men dens 8272 diskcontroller er et helt ekstra niveau af hovedpine sammenlignet med WD1770, du ofte vil se andre steder.

MSX og / eller ColecoVision / SG1000

Forskellige lydchips, samme CPU og video.Jeg tror faktisk, du kan komme temmelig langt ud af at ignorere timing-samspil, fordi videochippen holder sit eget RAM på armlængden. Men det er fliser og sprites og fire forskellige grafiktilstande, for sandsynligvis for en væsentlig opgave til et mikroprocesseringskursus.

Master System

Teknisk set en forbedret SG1000, der er alt, hvad maskinen gør plus en ekstra grafiktilstand, men den ekstra grafiktilstand er så meget bedre end de andre, at kun en titel bruger noget andet. Så det forenkler faktisk tingene noget, hvis du er glad inden for det område, hvor du for det meste ignorerer timing.

Men du taler stadig om factoring i sprite-prioriteter, kontrol af kollisioner pr. Pixel osv. Sandsynligvis for meget .

Fodnote: snyd med adgang til bånd

For en flok hjemmecomputere, der er nævnt ovenfor, kan du faktisk springe båndemulering over for alt, hvad der er kodet i standard-ROM-format ved blot at indsætte en passende fælde i system-ROMen og spoling ind fra kildefilen. Mange, men ikke alle, titler er helt afhængige af den indbyggede ROM til tape IO, så der kan få mange titler indlæst uden noget reelt forsøg på hardware.

I alle tilfælde er det et bodge-job hack, men det “gør, hvis den side af emulering ikke er vigtig for dig – du vil hellere bare fjerne den fra ligningen og ignorere, hvad der ikke virker.

Specifikt:

Vic-20:

• hvis programtælleren kommer til 0xf7b2, kopier den næste båndoverskrift til det sted, der er angivet med b3: b2, nul ud 0x90 og 0x93, og fortsæt fra 0xf7b5 (da du undgår en JSR);
• fælde 0xf90b, tjek for X = 0xe, hvis ja da få den næste bånddatakropp og skriv til emuleret hukommelse fra c2: c1, men ikke længere end af: ae uanset kroppens størrelse, sæt derefter bit 6 ved 0x90, ryd flagene for afbryd og afbryd og fortsæt fra 0xfccf.

Oric:

For ROM 1.0 skal du fange pcen på adresse 0xe630. For 1.1 skal du se efter adresse 0xe6c9.

Når du har fanget det, skal du indlæse A med den næste byte fra båndet og indstille nulflagget i henhold til dets værdi.

Så RTS.

Der er også et flag ved 0x67 på den originale ROM, eller 0x24d, der skelner mellem maskinens hurtige og langsomme båndkodninger, men det sædvanlige båndfilformat har bare de dekodede byte, så for en hurtig og beskidt emulering skal ikke bekymre dig om det.

Elektron:

Installer NOPer ved 0xf4e5, 0xf6de, 0xf6fa og 0xfa51 for at deaktivere båndgrene. OS vil nu prøve at indlæse bånddata, som om de var på en seriel ROM.

Cat pcen på 0xf0a8 og kontroller, at X register er lig med 14, og værdien på adressen 0x247 er nul. Så ved du, at ROMen prøver at hente den næste byte fra båndet.

Sæt den næste byte i Y, sæt A til 0 og RTS.

Det primære båndfilformat giver dig for det meste mulighed for at spole byte direkte fra filen (efter nogle trivielle chunk navi gation, og via ZLib eller en anden GZ-dekompressor, selvom du bare kunne gribe på forhånd).

ZX Spectrum:

(Denne er transskriberet fra meget gamle noter; det kan være værd at bekræfte mod en ROM-adskillelse)

Fæld pcen til at nå 0x056c i 48kb ROM. Grib den næste blok fra båndet (hvis du bruger en TAP-fil, får du den direkte; jeg hævder, at du ikke skulle gider at prøve at støtte TZX i denne slags projekter).

Hvis dens længde er mindre end værdien i DE, nulstil bære og returnere.

Sammenlign den første byte i blokken med værdien af B. Hvis de ikke stemmer overens, skal du nulstille bære og returnere.

Ellers skal du spole de første DE-byte, du kom til den adresse, IX pegede på, og indstille den lave bit af C og indstille bære.

Udfør derefter enten direkte en RET eller ellers spring bare pcen over foran til 0x05e2, som er RET, der normalt afslutter båndindlæsning.

128 kb-maskinerne inddeles i 48 kb ROM til båndindlæsning, så det samme hack gælder med forbehold for kontrol af, hvad der er side.

Kommentarer

• Dejlig skrivning. Jeg er enig med alt sagt – måske med to små tilføjelser til Apple II. Selv om det er rigtigt, at videohardwaren har brug for en hel del overvejelser, dens finesse kan fuldstændig ignoreres i emulering, som bare ækvivalens af visse bitmønstre skal oversættes til farve – overhovedet som A2, hvor det ofte kører med monokrom skærm, hvormed det kan efterlignes som almindelig bitmap uden yderligere detaljer. For det andet, så længe de perler, der skal spilles, er ProDOS-baserede, er der ikke behov for nogen detaljeret Disk II-emulering, da sådan fungerer med forskellige hardware.
• @Raffzahn hvad ville den enkleste form for et opslagstabel til farve output være?Når jeg resonnerer tilbage fra NTSC og behandler alt som nedbrydeligt til dobbelt høj opløsning, kan jeg forestille mig en tabel indekseret af en tre-bit tæller, der repræsenterer fase plus et fem-bit skiftregister for videooutput for at få en halv farvecyklus med et midtpunkt. Så en 256-posters tabel. Men det ‘ er meget naivt ræsonnement; har folk gjort det bedre?
• @Tommy: En enkel tilgang er simpelthen at bruge en gentagende firefarvet sekvens (jeg tror (rød, mørk gul, grøn, blå) til dobbelt-høj opløsning pixels og sløring skærmen lidt. Det vil ende med at efterlade farvekanter på tingene, men ægte skærme havde en tendens til at gøre det alligevel. Da Apple]

  Svar

  Jeg synes, at brugen af grafiske spil som et mål muligvis strækker dine elever for langt. At køre et spil kræver generelt god efterligning ikke kun af størstedelen af processorens funktioner, men også en masse hardware, ikke mindst videokredsløbene (som ofte er ret komplekse og i mange tilfælde introducerer en masse tidlige problemer). Hvis noget ikke fungerer korrekt, er resultaterne sandsynligvis meget dis udnævnelse. Jeg foreslår at starte med et lettere mål.

  Jeg sigter mod et system, der har en teksttilstandsgrænseflade snarere end grafisk, fordi sådanne grænseflader normalt er meget enklere og muligvis ikke har nogen specielle timingkrav der skal opfyldes (dvs. de fungerer ofte helt parallelt med processorens adgang til hukommelse uden at påvirke processoren overhovedet). Jeg vil også anbefale et system, der har et integreret maskinniveau overvågningsprogram, fordi dette vil hjælpe med fejlretning af programmer kører på maskinen uden at skulle implementere en debugger på emuleringsniveau.

  Et forslag baseret på mit nuværende personlige forskningsprojekt er Nascom 2-computeren. Dette er en relativt enkel Z80-baseret maskine med teksttilstandshardware, der interagerer ikke med CPUen (hvis der er strid, løses den til fordel for CPUen, hvilket betyder, at teoretisk set en håndfuld pixels i hver ramme muligvis ikke vises, hvis skærmen åbnes på samme tid som opdateringen er forekommer, men th er sandsynligvis ikke særlig mærkbar eller endda hyppig, så giver et brugbart resultat med meget enkel hardware). Præcis timing er derfor sandsynligvis ikke særlig vanskelig eller vigtig for denne maskine. Maskinens hardware er både enkel og veldokumenteret. Integrerede eksterne enheder er en UART (som kan bruges enten til en fjernterminal / printer eller til kassetteindlæsning og -besparelse …. hvilket betyder, at der ikke er behov for faktisk at efterligne kassettehåndtering på lydniveau, hvilket sparer en hel del implementeringstid) og et parallel IO-modul. De tilgængelige værktøjer tilskynder også eksperimentering på samlingssprog, hvilket jeg forestiller mig er et ønskeligt mål for dit kursus.

  En interessant ting ved denne maskine er, at der er et hul i de tilgængelige emuleringsmuligheder: bedst kendte webside om maskinen har anmodet om en javascript-baseret emulator, som de kan integrere på siden, men endnu har ingen leveret en.

  Svar

  Jeg har lavet to og lidt fra bunden emuleringer til Mac ved hjælp af Swift. Dette er mine personlige observationer baseret på min erfaring.

  Ingen af mine emuleringer er fuldstændig cyklusnøjagtige, hvilket fører til et par problemer.

  Commodore PET

  Dette var den første emulering, jeg skrev. Du har mindst brug for en 6502-emulering, en PIA-emulering, en VIA-emulering og en videoemulering.

  6502 er virkelig enkel og en fremragende processor til at begynde med. Det er også ret veldokumenteret. Visual6502-webstedet var uvurderligt for at udarbejde den nøjagtige opførsel af instruktioner, hvor dokumentation var tvetydig. Som en side, skrev jeg en emulering af en lidt senere processor (jeg glemmer hvilken), der udfyldte nogle af hullerne i instruktionssættet. Dette gjorde det lettere at skrive 6502 testkode (selv bare PHX og PHY gør nogle ting enklere. på den anden side vil enhver software, der brugte de “udokumenterede instruktioner” i den oprindelige 6502, bryde på min emulering.

  PIA og VIA er relativt enkle IO-chips at efterligne. Videodriveren kan være så enkel som læsning af skærmens RAM, oversættelse til ASCII eller en tæt tilnærmelse og tegning af den resulterende tekst i et vindue. Til sidst oprettede jeg et sæt bitmaps, der var nøjagtige kopier af PET-tegnsættet.

  Min vigtigste ressource til PET var “Programmering af PET / CBM” af Raeto West. Jeg har en original kopi, men der er PDF-ver sioner online. Også vigtigt er tilgængeligheden af BASIC og KERNAL ROMS.Du vil ikke omskrive operativsystemet.

  Efterligning af bånddrevet var en PITA. Min softwareversion var mindre pålidelig end den rigtige, som PET-ejere vil vide, at de virkelig siger noget. Jeg troede, at problemet er afhængigt af cyklusnøjagtige timingimpulser, og selvom min emulator tæller urimpulser, påkaldte den ikke nødvendigvis timeafbrydelsen nøjagtigt på det rigtige tidspunkt.

  Jeg havde mere succes med at skrive en emulering af de dobbelte diskdrev. Dette krævede også en robust IEEE 488-emulering, men diskdrevemuleringen var ret let. Det er ikke en hardwareemulering, det tager bare de kommandoer, der sendes af PET, og udfører dem ved hjælp af flade filer på Macens harddisk.

  Til sidst skrev jeg noget kode, der ville stoppe emulator, skal du direkte injicere en programfil i hukommelsen og derefter starte emulatoren igen. Dette viste sig at være så meget mere praktisk end at emulere diske eller bånd, at jeg holder op med at arbejde på dem.

  Min emulator fungerer godt nok med de fleste PET-koder. Desværre er der et problem med PET Space Invaders – sandsynligvis forårsaget af tastaturkoden – så det genkender ikke tastetryk korrekt. Jeg forsøgte heller ikke at adressere lydgenerering.

  Sinclair ZX Spectrum

  På nogle måder er dette endnu nemmere end PET. Du skal skrive en Z80-emulator, som er mere kompleks end 6502, men der er en CPM-testpakke, som du kan bruge til at verificere en masse af dens funktionalitet, du skal bare efterligne CPMs karakteroutput-underrutine for at gøre det brugbart. / p>

  De eneste andre chips, du har brug for at efterligne, er ULA, og du behøver ikke gøre meget af det, hvis du er parat til at give afkald på et bånddrev. Også videogeneratoren, som er lidt underlig i den måde, den adresserer skærmens RAM på.

  Den virkelig gode ting ved Spectrum er, at skærmen altid er i bitmap-tilstand, og OS opretter tegn ved direkte skrive skrivepixelmønstre. Du behøver ikke bekymre dig om et tegnsæt, fordi det på magisk vis er der, når du starter emulatoren med de indlæste Spectrum ROMer.

  Jeg fik Spectrum til det punkt, hvor jeg kunne indlæse og køre Manic Miner og det kunne afspilles, omend uden lyd. Det tog omkring tre måneder at arbejde måske otte timer om ugen fra start til slut.

  Commodore 64

  Dette er et igangværende arbejde. Naturligvis havde jeg allerede en 6502, som jeg ændrede for at give mig IO-porten på 6510. Indtil videre gør det banken skifte korrekt, er nogle af CIA-funktionaliteterne implementeret, og nok VIC II-funktionalitet er efterlignet til at give mig en PET-ækvivalent, dvs. den normale teksttilstand fungerer. Også grænsen og farvefarvehukommelsen fungerer.

  Jeg stadig har de mere komplicerede grafiske tilstande til at emulere og sprites, og jeg skulle være i stand til at gøre noget med lyden, fordi det er en separat chip, jeg er ikke afhængig af nøjagtig CPU-timing.

  TL; DR

  Den nemmeste emulering bortset fra CPUen var spektret. Jeg ville sandsynligvis starte med det, selvom en gammel CP / M 8080-baseret computer muligvis er endnu nemmere, hvis du kan få fat i CP / M.

  Yderligere observationer

  Du vil sandsynligvis have brug for en god tværsamler til din målplatform. Det bliver meget kedelig håndsamlingskode til enhedstest.

  Også en disassembler vil være nyttig. Jeg behøvede ikke at adskille Commodore BASIC-ROMerne, fordi adskillelser er frit tilgængelige på Internettet. Men da jeg prøvede at få Space Invaders til at arbejde, fungerede det først, og demontereren var uvurderlig for fejlfinding.

  Af denne grund gør cc65 suite et stærkt argument for at starte med en 6502-baseret maskine. Det fik en god samler og en fremragende demonterer inkluderet. Z80-situationen var ikke så god, men jeg fandt en rimelig samler til sidst kaldet z80asm. Jeg tror dog, at jeg var nødt til at kompilere det fra kilden.

  Desuden skal du have god solid dokumentation. Igen er 6502-dokumentationen online næsten uden sidestykke. Docs er mindre kommende for Spectrum, men det er så simpelt, du kan slippe af sted med en ganske sjusket ULA-emulering.

  Svar

  Sammen med alle de andre fine forslag, som et alternativ til Z-80 og CP / M, kan du overveje et generisk Motorola 6809 system til at køre FLEX eller muligvis OS-9 , begge Unix-inspirerede. Som et CLI-baseret system er der ikke noget behov for at få nogen nøjagtig timing.

  Også, hvis du “bygger simulatoren, er det snarere som at opbygge hardwaren; porting af operativsystemet var en reel opgave – som jeg gjorde i 1980erne – i modsætning til en klon-noget-til-uddannelsesopgave.”Starter det operativsystemet og kører programmerne?” er et meget realistisk mål.

  Da det kører et bærbart operativsystem, der kører på mange forskellige producenters hardware, betyder det, at de studerende ikke kun har en måde at gøre det på. Student A kan bygge en bit-kortvisning; Student B kan lave en UART og have en seriel grænseflade. Nogle prøver måske at få hver cyklus rigtige, nogle prøver måske bare at få alle operationer korrekte. Derfor i stedet for blot at kopiere noget uden nødvendigvis at forstå originalen designbegrænsninger, de studerende er involveret i et ordentligt teknisk spørgsmål: hvad er en god måde at gøre dette på?

  CPU

  • 6809 var unik på det tidspunkt, idet det var muligt at skrive en helt positionsuafhængig kode, som ville køre identisk, uanset hvor den var i hukommelsen.
  • Instruktionssættet var næsten udelukkende vinkelret
  • Som en 8-bit CPU med 16-bit adressebus er det ret simpelt
  • Undtagelsesmekanismen og effektiv -adressemanipulation ligner meget moderne processorer
  • Som et Motorola-design havde det hukommelseskortet IO snarere end specielle IO-instruktioner
  • Lettere at gøre end Z-80 (mange færre instruktioner ) eller 6502 (færre specielle tilfælde)
  • Materiale via https://en.wikipedia.org/wiki/Motorola_6809

  FLEX blev designet som et Unix-inspireret system til 8-bit CPUer

  • Det var specielt designet til bærbarhed, og for at få det til at starte krævede meget få systemopkald at blive implementeret – jeg tror bare tegnlæsning / skrivning, floppy bloklæsning / skrivning og en slags boot (læs sektor og spring til det).
  • Hardware-agnostisk til disse grundlæggende funktioner, hvilket gør simulering meget meget nemmere
  • Det er spændende at skrive bare et par funktioner og starte et helt operativsystem
  • Ingen grafik at bekymre sig om (hvilket er positivt eller negativt afhængigt af din opfattelse)
  • Meget tilgængeligt materiale, f ind via https://en.wikipedia.org/wiki/FLEX_(operating_system)

  OS-9 ens i hensigten

  • Mere Unix-lignende end FLEX, lidt sværere at porte, så vidt jeg husker
  • Senere portet til 68000
  • Meget tilgængeligt materiale, find via https://en.wikipedia.org/wiki/OS-9