Jeg setter CHIP-8 frem.

Dette systemet er egentlig en virtuell maskin utviklet av en eller annen grunn. Det er spill skrevet for CHIP-8. Den har noen få opkoder, en stabel, et par tidtakere og en bitmappet skjerm med lav oppløsning, men det er enkelt nok til at de første få emulatorer passer inn noen få kilobyte på tidlige 8-biters datamaskiner.

Det er mer enn noen få referanseimplementeringer du kan bruke.

Det er spill og så videre som er offentlig domene allerede, som her slik at du ikke trenger å oppgi dine egne spill.

Kommentarer

• Ayy for Chip 8. Det ‘ er enkelt å finne implementeringer på mange språk, og arkitekturen er enkel.
• CHIP-8 er en flott idé for en introduksjon til emu på grunn av sin enkelhet.Etter å ha skrevet en NES-emulator før, kan jeg fortelle deg at det å skrive CPU var ekstremt tidkrevende og kjedelig – og 6502 er enkelt så langt som CPUer går. I motsetning har CHIP-8 bare 35 veldig enkle instruksjoner. I tillegg var mange systemer avhengige av presis timing-oppførsel mellom CPU og resten av maskinvaren, mens CHIP-8 ikke har noe slikt krav.
• Kommentarer er ikke for utvidet diskusjon; denne samtalen er flyttet til chat .
• Jeg ‘ er en erfaren programmerer, men Jeg skrev aldri en emulator. Etter dette svaret tenkte jeg: » Hei, denne chip8 ser lett nok ut, jeg ‘ Jeg bruker kanskje noen timer på den «. Tre uker senere er jeg ‘ her fortsatt og prøver å finne ut hvorfor programmer fortsetter å hoppe ut av minne. Mye moro, også masse » hva i helvete «.
• Jeg lurer på om det hadde vært noen hindring for å fjerne vblank vent fra plot-sprite rutinen og legge til en eksplisitt vblank-vent instruksjon? CDP1802 er ikke ‘ ta speed demon, men det kan nesten helt sikkert tegne mer enn en sprite per ramme i fravær av vblank ventetiden.

Åh. Hyggelig spørsmål. Jeg prøver å gi noen få tips, men jeg vil vurdere problemet måte å bli besvart her i stedet for en mer meningsfull samtale. Ikke desto mindre:

---

[…] som gir studentene i oppgave å lage en emulator for et eldre system

Ganske kult.

fra bunnen av,

Hvis dette skal være virkelig fra bunnen av og i programvare, ville det egentlig ikke anser det som en oppgave som passer for førsteårsstudenter i en så begrenset periode. Med mindre det er en måte å ta ut sanntidskrav (som er enda mer relevante for spill), vil jeg heller være forsiktig.

Faktisk, siden det handler om EE, hvorfor ikke gjøre ekte maskinvare? Det er fortsatt lett å få (noen) klassiske CPUer og relaterte enheter. Kombinert med som et moderne LCD-skjerm, er maskinvareinnsatsen ganske gjennomførbar om noen få uker i detalj.

som et gruppeprosjekt som skal fullføres til slutten av klassen (som er, som påpekt, to semestre lange).

Hvilken kan være den tetteste tilstanden.

Jeg prøver å velge et godt målsystem for dette prosjektet, med hovedmålet at det skal være ganske enkelt å etterligne. Jo mindre periferiutstyr som skal emuleres, jo bedre. mindre quirks og bugs som må replikeres, også jo bedre.

Høres ut som et godt forsøk. Og viktigere, det fjerner noen tilsynelatende enkle systemer (som singleboardere) fra listen, ettersom de stoler på kompleks håndtering av I / O-enheter (som sanntidstilgang til porter for å drive LED-segmenter på tilsynelatende kontinuerlig måte).

Jeg ønsker å utsette studentene for de viktige begrepene assemb ly språk, instruksjonskoding, adresseringsmodi, CPU-registre, minnekartede maskinvareregister osv.,

Noe som kan gjøres med en ekte maskinvare som vel som en emulering, er ikke det?

Det aktuelle systemet bør ikke kreve syklusnøyaktig emulering eller triks som å jage skannelinjen.

Sammen med det underforståtte kravet til en videoutgang, krever dette en enkel ikke-akselerert bitmaplogikk.

Et annet krav gjelder ytelse. Studentene er absolutt ikke kjent med programvareoptimaliseringsteknikker, så det å prøve å etterligne selv den første Playstation eller Nintendo 64 vil sannsynligvis støte på ytelsesproblemer (kanskje til og med SNES og Genesis).

Jeg vil ikke frykte mye her, siden faktisk PC-maskinvare er ganske rask. De virkelige problemene her er ikke emuleringshastighet, men sanntidsaspekter – synkronisering av forskjellige emuleringsdeler – som krever en veldig forsiktig og finjustert programvaredesign. Ikke å forventes her. Ganske «racing the beam» -delen du nevnte.

På dette tidspunktet trenger studentene bare å være bekymret for å implementere emulatoren riktig, ikke effektivt. CPU-emulering vil absolutt implementeres av en tolk, ikke en oversetter / recompiler.

Likevel, selv for de mest primitive, er sanntidssynkronisering nødvendig for å spill et spill. I det minste er en synkronisering av skjermspor et must – ikke minst for å veksle simuleringen selv.

Spillets iboende behov for å bruke tidseffekter – og synkronisert skjermmanipulering på et finere nivå enn rammer – er noe som vil gjøre det mulig å kjøre ethvert ekte spill på den foreslåtte emulatoren.

Jeg vil velge et system som spill ble laget for, selv om nevnte system ikke var en dedikert videospillkonsoll. Jeg føler at det å være i stand til å kjøre spill på emulatoren ville være veldig motiverende for studentene.

Jeg er helhjertet enig her. Mye av suksessen til Andre LaMothe s eksperiment- og læringssystemer er basert på den fremste evnen til å gjøre spill.

For øyeblikket ser jeg for eksempel på NES, men det føles fortsatt litt komplisert, spesielt PPU. Finnes det enklere alternativer?

Det blir vanskelig ettersom de grunnleggende kravene strider mot hverandre. Bare vellykkede konsoller / datamaskiner fikk et stort utvalg av spill, men disse har også en mer kompleks maskinvarestruktur som gir flotte spill.

La oss sjekke noen kjente systemer. Jeg vil skille dem i «enkle» og «komplekse» systemer langs kompleksiteten i videologikken deres (* 1)

Enkle systemer

I første iterasjon er dette alle systemer uten en dedikert VDC / CRTC.

• Atari VCS – til slutt det ultimate systemet som skal brukes til å lære montør, jobbe på et ekstremt grunnleggende nivå uten imellom og ikke mye å ta vare på. Samtidig «er navnebroren for» racing the beam «-uttrykket.

  Når det er sagt, kan det fortsatt være et system å se etter, ettersom tidsavhengige deler er veldefinerte og (sammenlignet med annen video) ekstremt enkelt og lett å etterligne – bortsett fra at det ikke er førsteårs ting. Dessuten er det ekstremt godt dokumentert på generelt tilgjengelige kilder.

• Commodore PET – Et ganske enkelt system, spesielt siden hele videodelen kan emuleres ganske abstrakt, men VIA-er må i det minste delvis emuleres. Det viktigste inneholder bare to timingkilder (ved siden av klokken).

  Et flott pluss for PET (og oppfølging) er god dokumentasjon (også på grunn av sin enkelhet). Selv om den har en CRTC, har nesten ingen spill (eller annen programvare) brukt omprogrammering i det hele tatt, noe som gjør det enkelt og en ufullstendig (abstrakt) emulering mulig.

  På baksiden er det bare et ganske lite antall spill, og de fleste av dem er skrevet i BASIC, noe som kan kreve litt forskning for å finne mengden abstraksjon kontra detaljer i emulering.

• Apple II – Igjen, et utrolig godt dokumentert system med mye programvare. Mye av det monteringsbasert. Selv om maskinvaren er fullstendig dokumentert og bygget av kun TTL, er den ikke veldig enkel, og siden noen spill i stor grad er avhengige av quirks og tellingsløyfer for nøyaktig timing, kan emulering bli mye mer komplisert enn antatt ved første blikk.

  Et pluss for deg kan være at Apple II var ganske populær i Brasil (vel den gang).

• TRS-80 – Også her videologikken er bygget opp fra TTL, men mye enklere enn på Apple. Lignende annen I / O er ganske enkel. På den negative siden er det igjen et ganske lite antall spill.

Så langt kan de virkelige eldgamlene, men også noen senere systemer, klassifiseres som enkle:

• Sinclair Spectrum – Mens logikken gir noen triks, fløyter bjeller &, men det er en rett frem flislagt bitmapdesign. Så langt er sjansene gode for en emulering, bortsett fra, som vanlig, stod spill veldig mye på timing, noe som kompliserte emulering igjen.

  I tillegg til Apple II, der hvor ganske mange kloner i Brasil .

• En lignende sak kan gjøres for ORIC-familien

• Atari ST – Det kan være en overraskelse fra i dag av visningen, men Atari ST hadde ingen sofistikert video-maskinvare. Bare tre grafikkoppløsninger og en 9-biters CLUTT for opptil 16 farger samtidig. Noen få synkroniseringspunkter og en enkelt tidtaker. Pluss en mer moderne CPU og en dedikert lydchip. Høres ut som en kamp laget i himmelen, hvis ikke det ville være for programmerere av spill igjen. Også her innebar programvare en hel mengde triks for å lage fantastiske spill (* 2).

En første konklusjon for «enkle» systemer er at selv om maskinvaren kan være mindre komplisert, gikk programvaren veldig langt for å overvinne dette. sies at mindre komplekse systemer ikke trenger å gjøre en emulering mindre kompleks, ettersom ikke mer forskjellig maskinvare skal emuleres, men den enkle maskinvaren må følges veldig nær timing for å få eksisterende spillkode til å kjøre.

Komplekse systemer

Dette er generelt alle systemer med en sofistikert VDC

• 9918 ff .- Dette handler ikke så mye om et enkelt system, men til slutt den vanligste brukte VDC (TI kalte det VDP). Mens den ble utviklet for TI 99/4, solgte TI den til alle som var interessert. Det resulterte i flertallet av alle systemer (* 3) som bruker en 9918 eller en av dens oppfølgingsdesign (9928/38/58 / …).

  Spillkonsoller som Coleco Vision , Sega SG-1000 helt til Master System en brønn samt datamaskiner fra TI 99/4 eller Memotech MTX helt til hele MSX -verdenen brukte denne familien.

  Høres bra ut, ikke sant? Det er sikkert mange spill som skal brukes. Videre hjelper en slik VDP til å forenkle emulering ettersom den gir et klart skille mellom CPU og skjerm og begrenser hvilke «triks» et spill kan bruke til det VDP tilbyr, som igjen er klart definert. Og igjen, det er den eksisterende programvaren som gjør emulering vanskelig, for selvfølgelig brukte programmerere selvfølgelig timingtriks for å manipulere skjermen til rett tid. Nevnte noen «Racing the Beam»?

• Commodore VC20, C64, C16 osv. – Det samme gjelder for alle Commodores hjemme-datamaskiner. Selv om de er forskjellige i kompleksitet ved å ha sprites eller ikke, tilby timere eller ikke og lyd eller ikke, er det grunnleggende problemet er det samme som i 9918-familien: Programvare som bruker bestemte tidssituasjoner for å skape spilleffekter.

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

Jeg kan fortsette med spillsystemer som NES eller MegaDrive, men jeg avslutter listen her, da prinsippet skal være klart nå: Mens noen systemer kan være som mer komplisert å emuleres, er ikke det virkelige problemet kompleksiteten til videohardware, men når en programmerer «forbedrer» hva kan man gjøre ved smart programmering (* 4). Så det virkelige problemet for prosjektet ditt er ikke «så mye) maskinvaren (* 5), da den er programvaren, spesielt triks og verktøy som brukes i virkelige eksisterende spill .

Det er spesielt ille, ettersom du vil bruke (slik jeg leste det) eksisterende spill som motivasjon. Det vil ikke være mange som kjører på en mindre vanskelig sanntidsemulering.

Å redusere denne avhengigheten vil redusere antall spill som kjører riktig. Å redusere det til et nivå som gjør at det kan håndteres i en tidsbegrenset kurs, vil gjøre det nesten umulig å finne passende spill.

Konklusjon: Finne riktig avveining er en måte, men en som vil ta betydelig undersøkelser samtidig som det begrenser brukervennligheten.

---

Nå er det kanskje mulig å angripe dette fra en litt annen vinkel. La oss prøve noen:

• Bruk av eksisterende gammel maskinvare:

  Selv om dette er bevist (* 6) for å fungere, tilbyr høyest mulig kompatibilitet og brukervennlighet på grunn av åpne utviklingsmiljøer, kan det gå glipp av «build» -appellen for EE-studenter.

• Bruk eksisterende pedagogiske spillsystemer:

  Systemer som Andre LaMothe «s XGS er gode verktøy for å dykke ned i detaljert maskinvarebygging og programmering. Visst, noe lodding kreves (det er klar bygging tilgjengelig), de er nesten komplette programvaredefinerte systemer, gjennomgående dokumentert og tilbyr et stort spillbibliotek. For ikke å nevne bøkene hans om spillprogrammering.

  En flott bonus er at studentene kanskje kan ta systemet hjem og spille selv etter at kurset er avsluttet.

• Bygg ditt eget enkle system:

  Ta en klassisk CPU (for eksempel 6502), litt RAM, FLASH og en VIA pluss en FPGA for å implementere en veldig grunnleggende CRTC og ferdig. Studentene vil lodde det, kan lære om komponentene og deres interaksjon, inkludert FPGA-bruk (som kanskje er et must uansett i dag) og deretter kjøre programvaren på ekte maskinvare. Selv med små tall bør det være mulig å produsere et slikt brett rundt 50 Euro eller mindre. Som XGS-ideen vil den fungere etter at kurset er avsluttet – inkludert følelsen av eierskap som å være deres system.

  Selvfølgelig må studentene skrive sine egne spill, men enkle spill kan gjøres på ganske kort tid – for ikke å nevne at oppfølgingskurs like godt kan bruke spill den forrige klassen skrev.

• Gjør en emulering av «ditt eget» system

  I likhet med før, bortsett fra at alt er virtuelt. Det fikk fordelen av å være en brønn definert og lukker systemet, spesielt et der det ikke er noen begrensninger på grunn av en mindre «perfekt» emulering – Emuleringen er perfekt per definisjon og alle dens særegenheter er den systemet har. Ulempen er igjen programvaredelen.

• Bruk «myk» maskinvare:

  Det er et prosjekt av Neil Franklin som lager en rekke generaliserte systemkomponenter omtrent som klassiske datamaskiner hadde, men bruk av mikrokontroller i stedet for dedikerte chips. Den kombinerer emulering med ekte maskinvare. Mens komponenter fremdeles er utviklet som emulering, er disse ment å kjøre i en mikrokontroller og brukes omtrent som «ekte» chips. Ett system kan settes opp ved å bruke en SoftCPU-modul som emulerer for eksempel en 6502 med noe RAM og ROM, kombinert med en SoftVGA som leverer en terminal som et videogrensesnitt og et SoftPS2-emulerende tastatur og mus. Alle er koblet til via en parallell- eller seriell (SPI) buss som tillater tillegg av andre komponenter som også kan presenteres for emuleringen.

  Foruten å være alt om emulering, har den en begrenset mengde maskinvare som kan gjøres på et brødbrett (Likevel er det aldri for tidlig å begynne å lodde), det viser også en ganske typisk oppgave med dagens engineering – å erstatte tradisjonell logikk med mikrokontroller – i praktisk bruk.

  resultatet er et system som gir berøring og følelse av en ekte (gammel) datamaskin mens den bygges med moderne maskinvare som kjører parallelle emulasjoner.

• Bruk av en konfigurerbar emulator:

  Nei, dette handler ikke om MAME eller likt, men et emulatorrammeverk skrevet i JavaScript, som håndterer de generiske delene (inkludert timing), der studentene dine vil legge til emuleringene sine (som var et mål, var det ikke det?) for å danne et helt system. Siden JS er levert i kilden, kan til og med selve Framework modifiseres.

  Avhengig av kvaliteten på hver emulering, kan dette være brukbart for alt fra et enkelt demonstrasjonssystem til en fullstendig rekreasjon fra 1980-tallet. datamaskin.

Så kanskje noen av ovennevnte variasjoner kan være en god start?

---

* 1 – Jeg vil bare fokusere på video (og CPU) for å holde det enkelt. Også video alene vil allerede fungere godt for å luke ut komplette systemer. Lyd vil legge til en annen dimensjon og kan komplisere den langt utenfor omfanget av dette.

* 2 – Bare ta en titt på Xenon. En banebrytende vertikal rulling med flere skiftende lag, mange animerte objekter, som alle kjører superglatt i programvare. Faktisk var det så finjustert at det å ta det til det (vanligvis) mer dyktige Amiga (grafikkmessig) tok litt tid og resulterte i et noe mindre spill.

* 3 – Systemer designet ikke nødvendig solgte enheter. Så igjen, noen spillkonsoller var mer enn bare vellykkede, så det kan til og med få flertallet i antall.

* 4 – Blogginnleggene til hovedutvikleren av Glide64 renderer-plugin for N64-emulatorer har skrevet en serie med flere deler ( Intro , P .1 , P.2 , P.3 ) av blogginnlegg om hindringene han måtte klatre for å få videoemuleringsdelen til å fungere – alle handler ikke om kompleksiteten ved å emulere maskinvaren, men alle måter CPU endret og justerte utgangen ved siden av videologikken. Dette er enda mer bemerkelsesverdig med tanke på at N64 allerede er et ganske absolutt og lukket system.

* 5 – Faktisk vil jeg betrakte mer kompleks videohardware som en flott leksjon for EE-studenter, da det godt viser hva kan gjøres med noen få port i stedet for bunker med programvare – enda mer som de er i ferd med å gjøre maskinvare senere, er det ikke det?

* 6 – Stefan Höltgen ved FU Berlin bruker for eksempel gamle spillsystemer i klassene sine for å introdusere (ikke-EE) studenter til ekte maskinvare og ekte programmering og deres implikasjoner for hverdagsoppgaver (og spill).

Kommentarer

• @Tommy Vel, jeg vil gjerne unngå dette, da det ikke er noe lett svar. Det viktigste kan være, mens Z80 er noe » quirky «, er 68k alt annet enn enkel. Med alle utvidelsesordene (opp til CPU32), kan en enkelt instruksjon ha opptil 11 ord (22 byte) og avkoding er et alvorlig rot. Så igjen, alt avhenger av måten emulatoren er laget på. Z80 er en ganske rett frem 8080, lett å etterligne, med noen få modifikatorer som lett kan håndteres. For 68k, til og med bare den opprinnelige, vil det være mye mer arbeid.
• » oppgave som passer for førsteårsstudenter på så begrenset tid. » Han sa at dette er 3. års studenter, ikke førsteårsstudenter, og de ‘ har allerede fullført flere forutsetninger.
• @ wizzwizz4 Vel, uansett hva vår personlige mening er, er JS den juridiske arvingen til BASIC. Seriøs og på alle måter! Bare tenk på det.Den kjører ikke bare n ved siden av hver eneste datamaskin, den ‘ er til og med installert som standard, og det er nesten ingen måte å bli kvitt den uten å miste mye funksjonalitet. Enda mer, bare tenk på hvor mye dårlig og utrolig langsom programvare som skrives i JS – det perfekte beviset, er ikke ‘ ikke det?
• @Raffzahn Det ‘ er helt annerledes For det første hadde BASIC flere inkompatible implementeringer … Ohhh! Det er etterfølgeren til BASIC!
• De ‘ er fortsatt ikke førsteårsstudenter, som er førsteårsstudenter. Og jeg synes du burde gi OP fordelen av tvilen om at han ikke ville ‘ ikke tildele prosjektet hvis studentene ikke ‘ t har ønsket bakgrunn.

Det er noen gode ideer så langt.

Men noe å vurdere.

Hvis du gjør noe sånt som en CP / M-maskin, er de egentlig ganske enkle, spesielt siden alt er isolert av ikke bare BIOS, men også IN / UT-naturen. av 8080 / Z80-familien.

Det virker ikke for dårlig for meg å ha en CP / M-maskin som er målet for det første semesteret. (Jeg vet ikke pensum)

Men for eksempel trenger en grunnleggende CP / M-maskin ikke syklusnøyaktighet, den trenger ikke avbrudd. Det mest kompliserte det må gjøre er å avstemme tastaturet for å se om det er trykket på en tast. (I motsetning til å overvåke nedlasting og tasting eller noe annet.)

Deretter kan du i andre semester legge til krav som grensesnitt til en grafikkbrikke. Forekomsten ovenfor av SG-1000 kan lett være en CP / M-maskin i det første semesteret, og deretter lett forvandlet til SG-1000 i det andre (siden du har gjort Z80-delen ferdig i det første semesteret) .

Til slutt tror jeg det trenger klassen din å ha et akseptprogram som elevene kan kjøre for å bekrefte CPUen. Få ting som er mer spennende enn å feilsøke en dårlig CPU, spesielt med maskinspråk du kanskje ikke er kjent med .

6502-fellesskapet har testprogrammer som kan kontrollere at en CPU utfører alle instruksjonene riktig, jeg er ikke sikker på hva som er tilgjengelig for de andre CPUene.

Og hvis det er noen trøst i omfanget, jeg skrev både en simulator og en tilhørende montør av og på over en 2 ukers juleferie, hvis det gir deg noen hjelp til hvor store de faktiske prosjektene er. Grunnleggende CPU-er er ganske enkle.

Kommentarer

• På Z80 gir FUSE tester, men ikke alle er generiske eller nødvendigvis korrekte med hensyn til nøyaktig syklus. timing; de ‘ er også i et ad hoc tekstformat, men jeg ‘ har transkribert dem til JSON: github.com/TomHarte/CLK/tree/master/OSBindings/Mac/… – bruk tests.in.json til å angi starttilstander og finne ut hvordan lenge du skal løpe for, så tests.expected.json for å bekrefte resultatene. Der ‘ er også zexall og zexdoc, opprinnelig CP / M-filer, men allment tilpasset og veldig sakte. Å passere førstnevnte krever en haug med udokumenterte ting for å være riktig, og passere sistnevnte ‘ t.
• … og det eneste jeg ‘ vi noensinne har funnet for 6809, antar at noen tenkte å foreslå en Vectrex eller Coco / Dragon, finnes i en bredere Williams arkadeserie test suite på seanriddle.com/wetsold.html . For 6502 er jeg veldig ombord med testene til Klaus Dormann, Wolfgang Lorenz og AllSuiteA, som alle ser ut til å være mye mer fremtredende enn Z80- eller 6809-testene.
• @Tommy Så langt som Jeg er ‘ klar over at hver av Fuse ‘ -testene er nøyaktige. Vennligst skriv inn feil hvis de ‘ ikke er 🙂
• @PhilipKendall, se e-posten min fra 29/5/2017 for å smelte-emulator-utvikle re: DJNZ og om forskyvningen blir lest på en endelig iterasjon. Konklusjon fra Alan Cox om FUSE ‘ s testede oppførsel er riktig, var at den ‘ s » åpen for tolkning » basert på tilgjengelige kilder. Så jeg syntes » ikke nødvendigvis var korrekt » var rettferdig. Jeg burde nok ha vært tydelig skjønt: Jeg fant bare en håndfull avvik i teamet ditt ‘ s fortolkning av bevis og min egen. Beklager dårlig form på det.
• @Tommy – » Konklusjon fra Alan Cox om FUSE ‘ er testet atferd er riktig var at den ‘ s » åpen for tolkning » basert på tilgjengelig kilder » …mens jeg har mye respekt for mye av det Alan gjør, er det ‘ ganske enkelt å verifisere om den testede oppførselen er den samme som en faktisk Z80 CPU (spesielt for CMOS-versjoner som kan kjøres på brødbord med lave klokkehastigheter for å sette opp detaljerte tester veldig enkelt), så dette er definitivt et tilfelle der hvis han mener det ‘ er noe galt han burde være i stand til å demonstrere det veldig enkelt.

Kan jeg foreslå SG-1000 ?

Systemet er lite mer enn en gruppering av tre hyllebrikker – Z80, TMS9928A for grafikk og SN76489 for lyd, med kontrollerne som dumme grupper med NO (normalt åpne) brytere.

I programvare eller maskinvare kan du simulere eller etterligne en hvilken som helst del av dette isolert eller alt sammen for å produsere hele systemet.

Systemet bruker enkle ikke-bankomkoblede ROM-er til spillene sine, og de bruker vanligvis y ikke stole på noen triks som forstyrrelser i midten av skjermen eller syklusregning for å gi effekten. Bare et enkelt flisekart og et antall sprites på toppen. Jeg foreslår at dette er mye enklere enn et system som inneholder mange interagerende interne komponenter og intelligente patroner som NES.

Du burde gi dine egne spill å etterligne i stedet for å distribuere ulisensiert opphavsrettsbeskyttet materiale selvfølgelig.

Kommentarer

• … og for ordens skyld er ColecoVision nøyaktig den samme samlingen av komponenter, med forskjellig tilkobling logikk og veldig litt mer kompliserte joypads. Så en SG-1000-emulator er vanligvis lett å utvide for å støtte begge deler.
• Også bemerkelsesverdig at 9918 er en kompleks chip, med sprites, komplekse modi og data, som han ikke ‘ ikke vil bruke. Er det ikke ‘?

En enkel, enkel datamaskin som ZX Spectrum høres rimelig ut – Men det er rett og slett for mange gode emulatorer rundt for å gjøre dette til et nyttig alternativ. Jeg tror også 6502 er enklere å etterligne.

Så, et mulig alternativ kan være Oric-1 eller Atmos by Tangerine-systemer , som brukte et 6502-minne uten bank, ingen tilpassede sjetonger bortsett fra enkel video, og en relativt grei rammebuffer. Det er heller ikke så kjent som Spectrum, men det er programvare (spill) tilgjengelig for å få med noen enkle kompatibilitetstester (jeg tror noen «følelse av prestasjon» er ekstremt viktig for studenter). Det er allerede en rekke emulatorer tilgjengelig for Atmos (tre, så vidt jeg vet), men antallet er begrenset, noe som gjør det enkelt å finne ut om noen lurte og bare kopierte koden.

Ingen av Oric-spill var så sofistikerte etter min kunnskap at du ville trenge en 100% syklus-nøyaktig emulering for å kjøre spillene,

Kommentarer

• I ‘ d hevder at Oric-arkitekturen fraråder rasterracing ved ikke å ha en sidekanal med videokontrollregistre og ikke være satt opp slik at racing kan tenkes å øke fargeoppløsningen din (i motsetning til et Spectrum). Hvis det bare hadde to HIRES-buffere, sa jeg ‘ d det mer trygg. Er du enig i det?
• @Tommy I ‘ Jeg er ikke så kjent med Oric-videokretsen. Det jeg uansett vil si er at Oric hadde så kort levetid og en så begrenset brukerbase at sofistikerte teknikker for å tilpasse videoen som vi kjenner fra ZX Spectrum ikke var ‘ t utviklet (i det minste ikke i løpet av datamaskinens aktive levetid, der ‘ et antall interessante demoer her demozoo.org/platforms/ 49 )
• Å, da vil jeg ‘ gi bedre resonnement: Oric-videobrikken har modal tilstand, inkludert tekst- eller grafikkmodus, men ingen utsatte registre. Alt er satt av kontrollbyte i videostrømmen – inkludert forgrunn- og bakgrunnsattributter. Folk pleier å klage på det, fordi det betyr at hvis du vil ha gapløs grafikk, er du ‘ begrenset til fire farger per linje, hvor to av dem er bitvis komplement til de to andre. Noen av de moderne spillene ser fremdeles veldig bra ut – f.eks. Stormlord youtube.com/watch?v=QSDy-BC580M
• @Tommy Serialattributtene gjør programmeringen litt vanskeligere, jeg ‘ gjetning, men mengden attributtkollisjon er enda bedre enn på ZX Spectrum, regner jeg med.
• Xenon 1 trenger syklus nøyaktig, ellers låser den seg når skipet eksploderer (ansvarsfraskrivelse: Jeg skrev en oric-emulator for amigaen som heter amoric og snublet inn i dette problemet, men bare på akkurat dette spillet)

Basert på kriteriene dine, og behovet for å holde prosjektet interessant for studentene dine, vil jeg anbefale seriøst vurderer Vectrex Arcade System, som ble solgt av Milton Bradley tidlig på 1980-tallet.

Fordi Vectrex er unik når det gjelder å bruke en vektordisplay, i stedet for en rastervisning, gjør den ikke krever at det kompliseres noe komplisert videohardware. Skjermen styres av CPUen, og selve skjermen er enkel å etterligne på et moderne system og med god ytelse.

I tillegg til å etterligne vektordisplayet, er CPU ( Motorola 6809), og I / O-brikken (MOS 6522), representerer ikke for slim h av en utfordring ettersom de er enkle 8-biters deler som er veldig godt dokumentert.

Minnemodellen er også veldig enkel uten bankordninger som jeg ikke er klar over. Det er en vanlig PSG-lydbrikke i Vectrex, men å etterligne den kan betraktes som «Extra Credit».

I motsetning til andre enkle spillkonsoller på begynnelsen av 1980-tallet, har Vectrex-spillene holdt seg ganske bra, gitt dets evne til å gjengi jevn monokrom grafikk inkludert 3D-ramme. Dette fremgår lenger av populariteten til den moderne «hjemmebrygging» -utviklingen, der utviklere fortsetter å lage nye Vectrex-spill.

En endelig fordel for Vectrex er at det originale system-ROM-en kan distribueres fritt.

Kommentarer

• Bortsett fra at vectrex også fotter godt ‘ Racing the Beam ‘ cathegory, ikke ‘ t det?
• @Raffzahn, slik jeg forstår det, styrer Vectrex CPU elektronstrålen – nøyaktig det motsatte av en » som kjører strålen » situasjon der programvaren trenger å gjøre nøyaktig tidsendrede tilstandsendringer til fortsett med en eksternt tidsbestemt rasterskanning.
• @Mark Det ‘ er det samme med VCS. Også her styres strålen av CPUen. Uten at CPU har tilgang til WSYNC hver linje, og før linjen er ferdig, vil skjermen svikte. Og så vidt jeg forstår OP, handler det ‘ om ikke å gjenskape et system med strenge tidskrav – som er essensielle for Vectrex.
• @Raffzahn: CPUen i VCS styrer vertikal, men den kontrollerer ikke den horisontale. Det ‘ er ikke uvanlig at et spill sender ut dusinvis eller hundrevis av skannelinjer uten en mellomliggende WSYNC. I fravær av en WSYNC vil strålen være i samme horisontale stilling hver 76. syklus. Lagring av WSYNC er ofte den enkleste måten å vente på at strålen når høyre side av området som vises, men det er ‘ nesten ikke den eneste måten. En programmerer som var så tilbøyelig, kunne utnytte de intrikate detaljene i sprite-bevegelse og atferd til å skrive et spill som aldri brukte WSYNC i det hele tatt.
• Um, folkens, vi snakker om en emulator her. Det kommer ikke til å være et problem med fosforene falmer mens den emulerte CPU tar for lang tid å tegne neste ramme. Det er ingen » stråle » og det er absolutt ingen grunn til at emulatoren trenger » løp » siden emulatorskjermen vil forbli ganske statisk så lenge det er nødvendig mellom rammer.

Å lage en emulator fra bunnen av er relativt stor oppgave spesielt for uerfarne studenter og kan vise seg å være problematisk. Så du må virkelig være forsiktig med hvilken plattform du skal etterligne og hvilken info du skal dele / bruke. For meg er det beste valget en ZX 48K plattform da jeg vokste på den og er kjent med dens indre funksjoner, så svaret vil være partisk av det … Men vi må huske at studentene i dag vanligvis ikke så / brukte / visste det så mye som vi gjør … Det du trenger å oppnå er:

1. riktig CPU-iset-emulering

   selv om det er mange instruksjonsdokumenter der ute Du må være forsiktig da for eksempel på Z80 inneholder 99,99% av dem feil. Så du bør velge en testet referanse for dem, nå er den riktig (eller i det minste basisk funksjonell).

   Her er for eksempel Z80-isen min som passerer ZEXAL med 100% suksess:

   • min Zilog Z80A komplett instruksjonssett med maskinsyklus timing

   Z80 plattform har en stor fordel, og det er at det er omfattende testere for det som ZEXALL Trener som kan hjelpe med å feilsøke emulatoren mye.

   Jeg tror det der også var versjoner for i8080 men jeg vet ikke om slike testere for annen CPU-familie.

2. Timing

   vel for grunnleggende emulering er klokke-tics-metoden (eller struping) nok som er velkjent og brukt … Jeg ser ikke noe problem her. I dag har datamaskiner relativt god oppløsning for timing (på PC: RDTSC, på Windows PerformanceCounter, …).

   Den grunnleggende emulatoren kan ignorere INNHOLDET til den emulerte plattformen, men pass på at noen OS / spill / apper kan bli gjort ubrukelig hvis ikke etterlignet riktig. Dette gjelder ikke bare demoer. Den vanlige timingen på gamle datamaskiner kom fra noen avbrudd (vanligvis videooppdatering) og et begrenset antall sykluser der de kunne utføre før den. Men med påstand kan antall instruksjoner som er utført på samme tid være veldig forskjellige, og noen programmer kan strømme over og skade dem selv eller fryse. INNHOLDET er det vanskeligste å implementere med klokke-tics, så du bør unngå det for enhver pris … På den annen side med MC-nivåtider er det veldig enkelt og bare noen få linjer med kode.

3. Lyd

   dette er plattformavhengig problem, og du bør velge API som brukes til lydinngang / utgang riktig. For eksempel på windows er det eneste brukbare alternativet WAvEIN / WAVEOUT på grunn av lav ventetid og enkel bruk. DirectX er ubrukelig (var i det minste på det tidspunktet jeg prøvde å bruke den til en slik oppgave) på grunn av HØYE forsinkelser og ikke fungerte tilbakeringinger.

   Jeg brukte buffert tilnærming i stedet for direkte høyttalerkjøring slik at emuleringen din kan sprekke utførelsestiden i stedet for MC-nivå riktig utførelse (som jeg gjør uansett, men jeg tviler på at studentene ville være i stand til å gjøre det i den aktuelle tiden).

4. Video

   Denne er også plattformavhengig. .. og du bør bruke API studentene dine er kjent med. Selv strålesporing er relativt enkelt å implementere med enkel bitmap … På datamaskiner som ZX har Scanline-rekkefølgen spesiell betydning og kan være veldig distraherende for nybegynnerkodere, så det er bedre å bruke oversettelse LUT-tabeller som konverterer mellom adresse og y-koordinering frem og tilbake.

   De fleste eldre plattformer brukte 50Hz / 60Hz oppdateringsfrekvens og relativt liten oppløsning, så i dag burde datamaskiner selv med ikke godt optimalisert emulering fremdeles være raske nok til det. Hvis ikke, er det også et alternativ å hoppe over rammer …

5. annet HW og periferiutstyr

   Det absolutte minimumet er RAM / ROM-minne og tastatur. Minne er vanligvis veldig enkelt bare statisk matrise og eller noen sider som bytter side … Tastaturet kan emuleres ved å stille I / O i henhold til tastene som trykkes. I / O-en kan også være minnekartet til en matrise akkurat som minne. Fange ISR-rutine er også et alternativ, men som gjør tastaturet ubrukelig for tilpassede nøkkelhåndterere.

   Jeg vil ikke bry meg med periferiutstyr fra FDC, AY osv., Da emulatoren skal holdes så enkel som mulig. Men hvis du er heldig, kan det være noen studenter som vil være langt foran andre med dette prosjektet. For de kan du foreslå å implementere spennende funksjoner som FDC, DMA, til og med ekte lydkortlyd (for ekte bånd eller andre lydspillere) som muliggjør mange fine funksjoner for eksempel se:

   • Z8410 DMA-chip som GPU?

6. Filer

   Jeg vil gå for Z80 / SNA-filformater på å bruke. Det er fint å bruke TAP / TZX, men fra starten av vil emulatoren være ganske buggy, og derfor kan det hende at lasterutiner ikke fungerer som de skal, og det er vanskelig å bruke og feilsøke.

7. ROM

   dette er den mest problematiske delen ettersom mange ROM-er fremdeles ikke er gratis, og ved å trekke ut / laste ned / bruke dem til emulering kan du risikere juridiske problemer.

   Fra noen kommentarer her ser det ut til at ZX-ROM-er er offentlig domene nå … og det er også kommenterte ROM-pri Det gjør det mye lettere å feilsøke de første trinnene i emulatoren (når ingenting ennå fungerer).

   Men du bør alltid vurdere Emulering og juridiske ting spesielt hvis emulatorene plasseres et sted på internett

Her noen relaterte QA-lenker av meg:

• Hvordan skaffe CPU og andre maskinvarespesifikasjoner for emulatorutvikling
• Skrive en grafisk Z80 emulator i C eller C ++ Jeg anbefaler på det sterkeste å lese denne (spesielt for studentene dine) vil spare dem for mye tid og nerver
• Hva er riktig implementering for maskinvareemulering?

Leter du etter en system som ikke har blitt emulert mye? Jeg foreslår at du holder deg innenfor 8-biters datamaskiner (eller tidlig enkle 16/32 bit-ene), ZX Spectrum 48k er et relativt enkelt system – veldig godt dokumentert, ingen sprites, ingen lydbrikke, nei RAM-banker, enkel I / O, si Mple grafikk (men med et rart oppsett), ingen syklus perfekt emulering kreves, velkjent CPU, enkel kassethåndtering (kan gjøres enda enklere av ROM-feller). Det er tonn spill, mange av dem med tillatelig lisensiering.

Ulempen: det er en enorm mengde tilgjengelige emulatorer, mange selv retro-kategorien, og mange med kildekode tilgjengelig, så faren for juks og kopiering av annen kode er høy.

Og selvfølgelig vil det å jobbe med en emulator til et tidligere ikke emulert system gi ytterligere fordeler av følelsen av prestasjon.

Kommentarer

• Jeg hadde samme instinkt, men vil utvide ved å antyde at SNA og Z80 og veldefinerte nok øyeblikksbildeformater som du trenger ‘ Ikke engang bekymre deg for båndemuleringen. Og la ‘ s være ærlige, TZX er litt av en miasma på dette punktet.
• Jeg tror Spectrum ROM nå er i det offentlige området, som kan hjelpe (eller gjøre ting for enkle)
• ZX Spectrum er et godt eksempel på enkel maskinvare, men også en av ganske kompliserte programmeringsprogrammer for å telle sykluser (Racing the Beam) for å få ut brukbare spilleffekter.
• @Tommy Åh, jeg vil aldri foreslå ZX80 / 81 av samme grunn. Og selv om det ikke er en ekte Spectrum buff, har jeg sett noen gode timingavhengige koder for det. De fleste prominet skjermmanipulasjoner etter den delen har blitt vist, men før den kjører en gang rundt. Det ‘ er et veldig enkelt problem som finnes på mange systemer. Ikke noe stort problem, men tidsavhengig. For eksempel enkle emuleringsskjemaer som bare gir hastighet på rammenivå vil produsere dritt på raskere emuleringsverter … og så videre.
• @Stormcloud Spectrum ROM er ikke i det offentlige området, selv om tillatelse har vært gitt å distribuere den til bruk med emulatorer. ZX80 og ZX81 ROM-er er utgitt under GPL.

Kan jeg foreslå å ta en titt på noen tidlige arkadespill? Spesielt disse to 8080 / Z80 plattformene:

• Midway 8080 – Utviklet i 1975 og styrker Space Invaders . Bruker en 256x224x1 bit svart-hvitt rammebuffer i RAM.

• VIC Dual – Sega / Gremlin «s platform designet i 1977 – det mest kjente spillet er Carnival . Videoen er en 32×28 rekke med 8×8 tegn (alt i RAM) og kan støtte en enkel fargepalett, kartlagt til PROM.

Disse er veldig enkle å etterligne når du får Z80-emuleringen i bruk. Det er ingen morsomme scanline-triks eller rare CPU-ventetilstander. kontroller er tilgjengelige via bitmappede I / O-porter.

Du kan spille med disse plattformene interaktivt på http://8bitworkshop.com/ (Full beskrivelse: Jeg driver dette nettstedet og er forfatter av bøkene som er lenket på siden som beskriver disse plattformene)

Apple] [er også et godt valg for en 6502-basert plattform, selv om videoundersystemet er mer komplisert enn i de to arkadeplattformene.

Kommentarer

• For hva det ‘ er verdt, jeg tror Space Invaders er et inspirert forslag. Hvis minnet serverer det ‘ er det bare en 8080 med en 1bpp bitmappet skjerm, noe port IO for kontrollene, ikke noe forsøk på å kjøre raster, lyd som bare er av formen » utløserstøy X nå «, veldig avslappede nøyaktighetskrav, og det produserer et spill som de fremdeles av og til prøver å selge nå. Det ‘ er bare lovlighetsproblemet som kan gi pause, selv om jeg ‘ alltid er uklar på akademiske unntak.
• At ‘ er ganske riktig, ‘ er også en ekstern chip som hjelper til med 8080 ‘ mangel på tønnsskifter. ‘ Det bør ikke være noe lovlighetsproblem som etterligner maskinvaren (det ‘ er ikke opphavsrettsbeskyttet BIOS eller annen kode) og det ‘ er ganske enkelt å skrive ditt eget spill, f.eks: 8bitworkshop.com/v3.2.0/?platform=mw8080bw& file = game2.c

PET eller TRS80 kan fungere vi vil. Enkel maskinvare med tekst på skjermen, slik at de kan emuleres med rett tekst. Opprinnelig legger du til kode for sine merkelige tegnsett senere, og sannsynligvis ikke inneholder mye i veien for nøyaktig syklus-tellerkode.

Bonuside etter hvis du gå for en PET og legge til C64-støtte vil gi grafikk.

6502 er sannsynligvis enklere å etterligne.

Den endelige tanken kan være Ohio Scientific Superboard II eller i den britiske inkarnasjonen UK101 ettersom jeg ikke tror det har omprogrammerbar videomaskinvare.

Kommentarer

• Ja, alle tre (PET, TRS, Superboard (jeg glemte helt om den senere)) er flotte enkle maskiner og gode for emuleringer. Men mangler også et godt utvalg av spill som er klare til bruk. For ikke å nevne farger og som folk kan forvente i dag.

Digital PDP-8 er en veldig enkel arkitektur som det kan være enkelt å skrive en emulator for. Noen grunner til dette inkluderer:

• Bare 8 grunnleggende instruksjoner
• Ingen videogrensesnitt etc. å etterligne, bare terminal I / O
• Ingen behov for syklusnøyaktighet, den faktiske serien av maskiner i seg selv garanterte ikke den samme oppførselen på tvers av de forskjellige implementeringene.
• Kan starte med et enkelt oppsett (f.eks. en 4Kword-maskin som kjører FOCAL-69), og gradvis gjøre emulatoren mer komplisert (f.eks. en 32Kword-maskin med utvidet regning, som kjører OS / 8 fra en RK05-disk)
• Mange manualer tilgjengelig online
• MAINDEC-diagnostikken og deres instruksjoner er tilgjengelig online, som kan brukes til å teste at emuleringen fungerer som den skal

Dette dekker kanskje ikke alle dine krav, f.eks. minnekartet I / O, men det inkluderer absolutt ting som instruksjonskoding og adresseringsmodus. av dokumentasjonen går helt ned til det grunnleggende maskinvarenivået som kan være passende for et EE-kurs.

Kommentarer

• Et interessant poeng er at de fleste av systemene nevnt ovenfor har enten Z80- eller 6502-prosessorer, som begge mangler noe når det gjelder støttede adresseringsmodi. Hvis dekning av adresseringsmodi er viktig, har PDP-8 et mye bedre utvalg av dem å demonstrere.
• For » -spillet » aspekt av spørsmålet, jeg tror at Adventure fortsatt opprettholdes / gjenopplives for PDP-arkitekturer (men sjekk det – jeg kan ta feil).
• @TobySpeight You ‘ har rett, det blir opprettholdt eller gjenopplivet, men for PDP-10 , som er helt inkompatibelt med PDP-8.

ZX Spectrum-alternativet har allerede blitt fortalt: styrken er den helt enkle IO-maskinvaren og det faktum at mange eksisterende spill IKKE krever presis, syklus -korrekt emulering av alle quirks med det eneste unntaket for lyd (ikke noe i nærheten av å korrigere lyd uten syklus-eksakt emulering av CPU og korrekt nedprøving av den mellomliggende 1-bit lydstrømmen produsert av CPU).

Ethvert annet alternativ for spillmaskinvare som NES, G enesis og alle lignende sprite-baserte maskiner er ikke et alternativ, åpenbart, da det er mye tid som trengs for å lære den komplekse maskinvaren, utvikle måter å etterligne den, omgå mangler i emuleringen etc. For eksempel til og med «enkel» Super Mario spillet på NES vil ikke fungere med mindre sprite kollisjonsbit i PPU er riktig emulert.

De gjenværende alternativene IMHO er følgende:

1. tidlig tekstmodusbasert IBM PC
2. en av de eksisterende CP / M-maskinene
3. (ikke inkludert noen «store» maskiner før «mikro» -tiden)

Nøkkelpunktet her er tekstmodusvisning, det er ikke så vanskelig å etterligne og mye enklere å vise på vertsmaskinen (til og med ikke behov for å vise pikselgrafikk, jobbe med windowsing system / SDL / osv.!).

Imidlertid er det fortsatt behov for litt etterforskning for å samle inn ordentlige programmer å jobbe med, inkludert spill. Det er noen tekstmodus-spill i CP / M, og de bør også være noen for IBM PC.

Kommentarer

• Med en potensiell fordel av en CP / M-maskinen er at det ‘ vil være minst en som bare 8080-emulering vil gjøre?
• Hyggelig, men så igjen, det er ikke raly mange spill for IBM i tekstmodus, er det?
• @Raffzahn – det trenger bare å være en .
• @Jules Hehehe … ja rett. Men så sier jeg ‘ at minimum 8080 vil gjøre susen

Anta at det er noe bidrag, dette er mine direkte notater om maskinene jeg har skrevet emulatorer for, i omtrentlig lansering kronologisk rekkefølge, forhåpentligvis for å tilby litt farge på filformater osv.:

Atari 2600

Det særegen ved Atari 2600 er synergien mellom prosessor og grafikkutgang; spill er implementert en sanntidsfunksjon som leverer grafiske komponenter til videoutgangen mens rasteren går. Så jeg tror dette er et dårlig valg for det oppgitte formålet – det virkelige harde arbeidet med å skrive en 2600-emulator er timingen og samspillet utenfor mikroprosessoren.

Apple II

Relativt enkel maskinvare, men veldig nyansert, med flere grafikkmodus, og du må gå i retning av å lære NTSC-video for å kunne dekode fargen. Å emulere Disk II er også stort sett et must, men det er litt av en søken i seg selv som de vanligste filformatene forventer at du skal gi en Apple GCR-koder.

ZX80 / 81

Det er også sannsynligvis altfor komplisert for det oppgitte formålet. Den sentrale innblandingen er å omforme CPUens oppdateringssyklus og en delmengde instruksjoner henter for å skanne video. Hvis du valgte å ikke implementere den mekanismen som originalen, vil du bare ha ROM-standard tekstmodus.

Commodore Vic-20

Dette er en vanlig bitmappet maskin med en enkel prosessor i 6502 og en anstendig mengde spill, hvorav noen ble levert på kassetten, noe som fritar deg fra behovet for å etterligne et bånd eller en diskstasjon. Den eneste fluen i salven er dens 6522s; dette er kombinasjonstimer / shifter / input / output chips med en hel masse quirks. Men en fin fordel med Vic-20 er at den vil starte opp så langt som BASIC-ledeteksten uten å fungere 6522s, og BASIC selv vil fungere med bare timerne til 6522 implementert , til og med unøyaktig.

Den korte tiden som markedsleder før ankomsten av C64 begrenser også antall titler som bruker avansert maskinvare – det er samtidige eksempler på rasterracing som Imagic-titlene , men de er i mindretall.

Filformatene som data blir bevart i er et rot , men å begrense deg til kassettstøtte og være forsiktig med å bruke bare de titlene som ble levert på kassetten, bør løse dette problemet.

ZX Spectrum

Dekket andre steder; Jeg synes et godt valg. Spesielt hvis du holder deg til øyeblikksbildefilformatene.

Oric 1 / Atmos

Dekket andre steder; et anstendig valg, men det er en annen av de irriterende 6522-ene der inne. De fleste spill er tilgjengelige på bånd, du må støtte alt det.

Acorn Electron

Bitmapped, en 6502 pluss relativt enkel ekstern logikk, men seks forskjellige grafikkmodi og timing vil være et problem – kostnadene for hver syklus er en funksjon av området du får tilgang til (ROM versus RAM), grafikkmodus (40-kolonne versus 80-kolonne moduser) og muligens gjeldende grafikkutgangstilstand (80-kolonnemodus blokkerer RAM-tilgang i løpet av pikselområdet; 40-kolonnemodus ikke). Men du kan bare modellere det som en 1 MHz-maskin for de fleste spill, og for det meste komme unna med en linjesentrert versjon av grafikkutdata.

Det er et lite antall spill tilgjengelig på ROM, men heldigvis vil båndmaskinvaren for det meste tillate en emulering av veldig lav kvalitet: det er av typen som gir en avbryt ved byte-mottakelse, med bare to titler som jeg kan tenke meg å gjøre dypere introspeksjon enn det.

Amstrad CPC

Sannsynligvis en for å unngå for det oppgitte formålet – den har en 6845 CRTC, noe som gir veldig konfigurerbar grafikkutgang og derfor mange titler som kjører rasteren. Diskbruk var også ganske gjennomgripende, men diskkontrolleren 8272 er et helt ekstra nivå av hodepine sammenlignet med WD1770 du ofte vil se andre steder.

MSX og / eller ColecoVision / SG1000

Ulike lydbrikker, samme CPU og video.Jeg tror faktisk du kan komme ganske langt fra å ignorere timing-samspillet fordi videobrikken holder sin egen RAM på armlengden. Men det er fliser og sprites, og fire forskjellige grafikkmoduser, for sannsynligvis en altfor betydelig oppgave for et mikroprosesseringskurs.

Master System

Teknisk sett en forbedret SG1000, som er alt maskinen gjør pluss en ekstra grafikkmodus, men den ekstra grafikkmodusen er så mye bedre enn de andre at bare en tittel bruker noe ellers. Så det forenkler faktisk ting litt hvis du er glad for å for det meste ignorere timing.

Men du snakker fremdeles om faktorisering i sprite-prioriteringer, sjekk for kollisjon per piksel osv. Sannsynligvis for mye .

Fotnote: juks med båndtilgang

For en haug med hjemmemaskinene som er nevnt ovenfor, kan du faktisk hoppe over båndemulering for alt som er kodet i standard ROM-format ved å bare sette inn en passende felle inn i system-ROM og spole inn fra kildefilen. Mange, men ikke alle, titler er helt avhengige av den innebygde ROM-en for tape IO, slik at du kan få mange titler lastet uten noe reelt maskinvareforsøk.

I alle tilfeller er det et hakkejobb, men det vil gjøre hvis den siden av emuleringen ikke er viktig for deg – du vil heller bare fjerne den fra ligningen og ignorere det som ikke fungerer.

Spesielt:

Vic-20:

• hvis programtelleren kommer til 0xf7b2, kopier neste tapehode til stedet angitt av b3: b2, null ut 0x90 og 0x93, og fortsett fra 0xf7b5 (ettersom du unngår en JSR);
• felle 0xf90b, sjekk om X = 0xe, hvis så da få neste bånddatakropp og skriv til emulert minne fra c2: c1, men ikke lenger enn af: ae uansett kroppsstørrelse, sett deretter bit 6 på 0x90, tøm bære- og avbryt flagg, og fortsett fra 0xfccf.

Oric:

For ROM 1.0, fang PCen på adresse 0xe630. For 1.1, se etter adresse 0xe6c9.

Når du får tak i det, laster du A med neste byte fra båndet, og setter nullflagget i henhold til verdien.

Deretter RTS.

Det er også et flagg ved 0x67 på den originale ROM-en, eller 0x24d som skiller mellom maskinens raske og langsomme båndkodinger, men det vanlige båndfilformatet har bare de dekodede byte, så for en rask og skitten emulering trenger ikke bekymre deg for det.

Elektron:

Installer NOPs på 0xf4e5, 0xf6de, 0xf6fa og 0xfa51 for å deaktivere båndgrenene. OS vil nå prøve å laste inn bånddata som om det var på en seriell ROM.

Cat PCen på 0xf0a8 og sjekk at X registeret er lik 14 og verdien på adressen 0x247 er null. Da vet du at ROM prøver å hente neste byte fra båndet.

Sett neste byte i Y, sett A til 0 og RTS.

Det primære båndfilformatet lar deg for det meste spole byte direkte fra filen (etter noen trivielle deler av navi gation, og via ZLib eller en annen GZ-dekompressor, selv om du bare kunne pakke ut på forhånd).

ZX Spectrum:

(Denne er transkribert fra veldig gamle notater; det kan være verdt å bekrefte mot en ROM-demontering)

Fang PC-en når 0x056c i 48 kb ROM. Ta tak i neste blokk fra båndet (hvis du bruker en TAP-fil, får du den direkte. Jeg vil hevde at du ikke skal bry deg om å prøve å støtte TZX i denne typen prosjekter).

Hvis lengden er mindre enn verdien i DE, tilbakestill bære og retur.

Sammenlign den første byten i blokken med verdien av B. Hvis de ikke samsvarer, tilbakestill bære og returnere.

Ellers spoler du de første DE-bytene du fikk til adressen som IX pekte på, og satte den lave biten av C og satte bære.

Deretter kan du enten utføre en RET direkte eller bare hoppe over PCen frem til 0x05e2, som er RET som normalt avslutter kassettbelastning.

128 kb maskinene seguerer inn i 48 kb ROM for kassettinnlasting, slik at samme hack gjelder med forbehold om å sjekke hva som er sidet.

Kommentarer

• Hyggelig skriving. Jeg er enig i alt sagt – kanskje med to små tillegg til Apple II. Selv om det er sant at videomaskinvaren trenger en del tanker, dens finesse kan fullstendig ignoreres i emulering, som bare ekvivalens av visse bitmønstre må oversettes til farge – hvis i det hele tatt, som A2 der det ofte kjøres med monokrom skjerm, som det kan emuleres som vanlig bitmap uten ytterligere detaljer. For det andre, så lenge perlene som skal spilles er ProDOS-baserte, er det ikke nødvendig med noen detaljert Disk II-emulering, da den fungerer med forskjellige hardware.
• @Raffzahn hva ville den enkleste formen for et oppslagstabell for fargeutgang være?Når jeg resonnerer fra NTSC, og behandler alt som nedbrytbart til dobbelt høyoppløselig, kan jeg forestille meg et bord indeksert av en tre-bits teller som representerer fase pluss et fem-bits skiftregister for videoutgang for å få en halv fargesyklus med et midtpunkt. Så en 256-oppføringstabell. Men det ‘ er veldig naivt resonnement; har folk gjort det bedre?
• @Tommy: En enkel tilnærming er å bare bruke en gjentatt firefargesekvens (jeg tror (rød, mørk gul, grønn, blå) for dobbel høyoppløselige piksler og uskarphet skjermen litt. Det vil ende opp med å etterlate fargekanter på ting, men ekte skjermer hadde en tendens til å gjøre det uansett. Siden Apple]

  Svar

  Jeg tror det å bruke grafiske spill som mål muligens strekker elevene for langt. Å kjøre et spill krever generelt god etterligning ikke bare av flertallet av prosessorens funksjoner, men også mye maskinvare, ikke minst videokretsene (som ofte er ganske komplekse og i mange tilfeller introduserer mange tidlige problemer). Hvis noe ikke fungerer riktig, er resultatene sannsynligvis veldig dis utnevne. Jeg foreslår at du starter med et enklere mål.

  Jeg vil sikte mot et system som har et tekstmodusgrensesnitt, i stedet for grafisk, fordi slike grensesnitt vanligvis er mye enklere, og kanskje ikke har noen spesielle timingkrav som må oppfylles (dvs. de fungerer ofte helt parallelt med prosessorens tilgang til minne uten å påvirke prosessoren i det hele tatt). Jeg vil også anbefale et system som har et integrert skjermprogram på maskinnivå, fordi dette vil hjelpe feilsøkingsprogrammer kjører på maskinen uten å måtte implementere en feilsøking på emuleringsnivå.

  Et forslag basert på mitt nåværende personlige forskningsprosjekt er Nascom 2. datamaskinen. Dette er en relativt enkel Z80-basert maskin med tekstmodus maskinvare som samhandler ikke med CPUen (hvis det er strid, løses den til fordel for CPU-en, noe som betyr at teoretisk sett ikke en håndfull piksler i hver ramme kan vises hvis du får tilgang til skjermen samtidig som oppdateringen er forekommer, men th er sannsynligvis ikke spesielt merkbar eller til og med hyppig, så gir et brukbart resultat med veldig enkel maskinvare). Nøyaktig timing vil derfor sannsynligvis ikke være spesielt vanskelig eller viktig for denne maskinen. Maskinvaren er både enkel og godt dokumentert. Integrerte periferiutstyr er en UART (som kan brukes enten til en ekstern terminal / skriver eller for kassettinnlasting og lagring …. noe som betyr at du ikke trenger å faktisk etterligne kassetthåndtering på lydnivå, og dermed sparer en god del implementeringstid) og en parallell IO-modul. De tilgjengelige verktøyene oppmuntrer også til eksperimentering på monteringsspråk, som jeg forestiller meg er et ønskelig mål for kurset ditt.

  En interessant ting med denne maskinen er at det er et gap i de tilgjengelige emuleringsalternativene: mest kjente nettside om maskinen har bedt om en javascript-basert emulator som de kan legge inn på siden, men foreløpig har ingen gitt en.

  Svar

  Jeg har gjort to og litt fra bunnen av emuleringer for Mac ved hjelp av Swift. Dette er mine personlige observasjoner basert på min erfaring.

  Ingen av emuleringene mine er helt syklusnøyaktige, noe som fører til noen få problemer.

  Commodore PET

  Dette var den første emuleringen jeg skrev. Du trenger minst en 6502-emulering, en PIA-emulering, en VIA-emulering og en videoemulering.

  6502 er veldig enkel og en utmerket prosessor til å begynne med. Det er også ganske godt dokumentert. Visual6502-siden var uvurderlig for å utarbeide den eksakte oppførselen til instruksjonene der dokumentasjonen var tvetydig. Som en side til siden skrev jeg en emulering av en litt senere prosessor (jeg glemmer hvilken) som fylte ut noen av hullene i instruksjonssettet. Dette gjorde det lettere å skrive 6502 testkode (selv bare PHX og PHY gjør noen ting enklere. På på den annen side vil all programvare som brukte de «udokumenterte instruksjonene» i den opprinnelige 6502 bryte på emuleringen min.

  PIA og VIA er relativt enkle IO-brikker å etterligne. Videodriveren kan være så enkel som lese skjerm-RAM, oversette til ASCII eller en nær tilnærming og tegne den resulterende teksten i et vindu. Til slutt opprettet jeg et sett med bitmaps som var nøyaktige kopier av PET-tegnsettet.

  Min viktigste ressurs for PET var «Programming the PET / CBM» av Raeto West. Jeg har en original kopi, men det er PDF-ver sjoner på linje. Også viktig er tilgjengeligheten av BASIC og KERNAL ROMS.Du vil ikke skrive om operativsystemet.

  Å emulere båndstasjonen var en PITA. Programvareversjonen min var mindre pålitelig enn den virkelige, som PET-eiere vet at det virkelig sier noe. Problemet, tenkte jeg, er at det er avhengig av nøyaktige timingspulser og selv om emulatoren min teller klokkepulser, påkalte den ikke nødvendigvis tidsavbruddet på akkurat riktig tidspunkt.

  Jeg hadde mer suksess med å skrive en emulering av de to diskstasjonene. Dette krevde en robust IEEE 488-emulering også, men diskstasjonsemuleringen var ganske enkel. Det er ikke en maskinvareemulering, det tar bare kommandoene som PET sender og utfører dem ved hjelp av flate filer på Mac-harddisken.

  Til slutt skrev jeg litt kode som ville stoppe emulator, direkte injisere en programfil i minnet og deretter starte emulatoren igjen. Dette viste seg å være så mye mer praktisk enn å emulere disker eller bånd at jeg sluttet å jobbe med dem.

  Min emulator fungerer bra nok med de fleste PET-koder. Dessverre er det et problem med PET Space Invaders – sannsynligvis forårsaket av tastaturkoden – så den gjenkjenner ikke tastetrykk ordentlig. Jeg prøvde ikke å adressere lydgenerering.

  Sinclair ZX Spectrum

  På noen måter er dette enda enklere enn PET. Du må skrive en Z80-emulator som er mer kompleks enn 6502, men det er en CPM-testpakke som du kan bruke til å verifisere mye av funksjonaliteten, du trenger bare å etterligne CPMs tegnutgangssubrutine for å gjøre den brukbar. / p>

  De eneste andre sjetongene du trenger å etterligne er ULA, og du trenger ikke gjøre mye av det hvis du er forberedt på å gi avkall på en båndstasjon. Også videogeneratoren, noe som er litt rart i måten den adresserer skjerm-RAM på.

  Den virkelig fine tingen med Spectrum er at skjermen alltid er i bitmap-modus og operativsystemet oppretter tegn ved direkte skrive skrivepikselmønstrene. Du trenger ikke å bekymre deg for et tegnsett fordi det magisk er der når du starter opp emulatoren med Spectrum ROM-ene lastet.

  Jeg fikk Spectrum til det punktet hvor jeg kunne laste og kjøre Manic Miner og det var spillbart, om enn uten lyd. Det tok omtrent tre måneder å jobbe kanskje åtte timer i uken fra start til slutt.

  Commodore 64

  Dette er et pågående arbeid. Selvfølgelig hadde jeg allerede en 6502, som jeg modifiserte for å gi meg IO-porten til 6510. Så langt gjør den banken å bytte riktig, er noen av CIA-funksjonalitetene implementert, og nok VIC II-funksjonalitet blir emulert for å gi meg en PET-ekvivalent, dvs. at normal tekstmodus fungerer. Også fargeminnet for kant og tegn fungerer.

  Jeg fremdeles har de mer kompliserte grafikkmodusene å etterligne og sprites, og jeg burde være i stand til å gjøre noe med lyden fordi det er en egen chip, jeg er ikke avhengig av nøyaktig CPU-timing.

  TL; DR

  Den enkleste emuleringen, bortsett fra CPU var spektrumet. Jeg ville sannsynligvis begynne med det, selv om en gammel CP / M 8080-basert datamaskin kan være enda enklere hvis du kan få tak i CP / M.

  Ytterligere observasjoner

  Du vil sannsynligvis trenge en god krysssamler for målplattformen din. Det blir veldig kjedelig håndsamlingskode for enhetstester.

  En demonterer vil også være nyttig. Jeg trengte ikke å demontere de grunnleggende ROM-ene til Commodore fordi demonteringer er fritt tilgjengelig på Internett. Men da jeg prøvde å få Space Invaders til å fungere, fungerte det ikke først, og demontereren var uvurderlig for feilsøking.

  Av denne grunn gjør cc65 suite et sterkt argument for å starte med en 6502-basert maskin. Den har en god montør og en utmerket demonterer inkludert. Z80-situasjonen var ikke så bra, men jeg fant en rimelig montør til slutt kalt z80asm. Jeg tror jeg måtte samle det fra kilden skjønt.

  Også, du trenger god solid dokumentasjon. Igjen er 6502-dokumentasjonen online uten sidestykke. Dokumenter er mindre kommende for Spectrum, men det er så enkelt, du kan slippe unna med en ganske skummel ULA-emulering.

  Svar

  Sammen med alle de andre fine forslagene, som et alternativ til Z-80 og CP / M, kan du vurdere et generisk Motorola 6809 -system for å kjøre FLEX eller muligens OS-9 , begge Unix-inspirerte. Som et CLI-basert system er det ikke nødvendig å få noen nøyaktig timing.

  Hvis du bygger simulatoren, er det heller som å bygge maskinvaren; porting av operativsystemet var en real task – som jeg gjorde på 1980-tallet – i motsetning til en klone-noe-for-utdanning-oppgave.»Starter det operativsystemet og kjører programmene?» er et veldig realistisk mål.

  Ettersom det kjører et bærbart operativsystem som kjører på mange forskjellige produsenters maskinvare, betyr det at studentene ikke bare har en måte å gjøre det på. Student A kan bygge en bit-kartvisning; Student B kan lage en UART og ha et serielt grensesnitt. Noen vil kanskje prøve å få alle sykluser rett, noen vil kanskje bare prøve å få alle operasjoner riktig. Derfor i stedet for å bare prøve å kopiere noe uten nødvendigvis å forstå originalen designbegrensninger, studentene er engasjert i et skikkelig ingeniørspørsmål: hva er en god måte å gjøre dette på?

  CPU

  • 6809 var unik den gangen ved at det var mulig å skrive helt posisjonsuavhengig kode, som ville kjøre identisk uansett hvor den var i minnet.
  • Instruksjonssettet var nesten helt ortogonalt
  • Som en 8-biters CPU med 16-biters adressebuss er det ganske enkelt
  • Unntaksmekanismen og effektiv -adressemanipulering er veldig lik moderne prosessorer
  • Som et Motorola-design hadde det minnekartet IO i stedet for spesielle IO-instruksjoner
  • Lettere å gjøre enn Z-80 (mange færre instruksjoner ) eller 6502 (færre spesielle tilfeller)
  • Materiale via https://en.wikipedia.org/wiki/Motorola_6809

  FLEX ble designet som et Unix-inspirert system for 8-biters CPUer

  • Den ble spesielt designet for bærbarhet, og for å få den til å starte opp, var det svært få systemanrop som måtte implementeres – jeg tror bare tegnlesing / skriving, diskettblokklesing / skriving og en slags boot (les sektor og hopp til det).
  • Maskinvare-agnostisk for disse grunnleggende funksjonene, noe som gjør simulering mye lettere
  • Det er spennende å skrive bare noen få funksjoner og starte et helt operativsystem
  • Ingen grafikk å bekymre seg over (noe som er positivt eller negativt avhengig av ditt syn)
  • Mye tilgjengelig materiale, f ind via https://en.wikipedia.org/wiki/FLEX_(operating_system)

  OS-9 lignende i hensikt

  • Mer Unix-lignende enn FLEX, litt vanskeligere å portere, så vidt jeg husker
  • Senere portert til 68000
  • Mye tilgjengelig materiale, finn via https://en.wikipedia.org/wiki/OS-9