Jag sätter CHIP-8 framåt.

Detta system är i huvudsak en virtuell maskin som utvecklats av någon anledning. Det finns spel skrivna för CHIP-8. Den har några opkoder, en stack, ett par timers och en bitmappad skärm med låg upplösning, men det är enkelt nog att de första emulatorer passar in några kilobyte på tidiga 8-bitarsdatorer.

Det finns mer än några referensimplementeringar du kan använda.

Det finns spel och så vidare som finns offentligt. domän redan, som här så att du inte behöver ge dina egna spel.

Kommentarer

• Ayy för Chip 8. Det ’ är enkelt att hitta implementeringar på många språk och arkitekturen är enkel.
• CHIP-8 är en fantastisk idé för en introduktion till emu på grund av dess enkelhet.Efter att ha skrivit en NES-emulator tidigare kan jag berätta att det var extremt tidskrävande och tråkigt att skriva CPU: n och 6502 är enkel så långt som processorerna går. Däremot har CHIP-8 bara 35 mycket enkla instruktioner. Dessutom förlitade sig många system på exakt timingbeteende mellan CPU: n och resten av hårdvaran, medan CHIP-8 inte har något sådant krav.
• Kommentarer är inte för längre diskussion; denna konversation har flyttats till chatt .
• Jag ’ är en erfaren programmerare, men Jag skrev aldrig en emulator. Efter det här svaret tänkte jag: ” Hej, det här chipet ser tillräckligt enkelt ut, jag ’ Jag spenderar kanske några timmar på det ”. Tre veckor senare är jag ’ fortfarande här och försöker lista ut varför program fortsätter att hoppa ur minnesutrymmet. Mycket kul, också massor av ” vad fan ”.
• Jag undrar om det skulle ha varit någon hinder för att ta bort vblank wait från plot-sprite-rutinen och lägga till en uttrycklig vblank-wait-instruktion? CDP1802 är inte ’ ta hastighetsdemon, men det kan nästan säkert rita mer än en sprite per bild i frånvaro av vblank väntan.

Åh. Trevlig fråga. Jag kommer att försöka ge några tips, men jag anser att frågan väg till bred ska besvaras här istället för en mer meningsfull konversation. Ändå:

---

[…] i uppdrag för eleverna att skapa en emulator för ett äldre system

Ganska coolt.

från grunden,

Om detta är tänkt att vara riktigt från början och i programvara, skulle det inte riktigt anser att det är en uppgift som är passande för nybörjare under en så begränsad tid. Om det inte finns ett sätt att ta ut realtidskrav (som är ännu mer relevanta för spel), skulle jag hellre vara försiktig.

Faktum är att eftersom det handlar om EE, varför inte göra riktig hårdvara? Det är fortfarande lätt att få (några) klassiska processorer och relaterade enheter. Kombinerat med som en modern LCD-skärm är hårdvaruinsatsen ganska genomförbar på några veckor i detalj.

som ett gruppprojekt som ska slutföras till slutet av klassen (som är, som påpekats, två terminer lång).

Vilket kan vara det tätaste tillståndet.

Jag försöker välja ett bra målsystem för detta projekt, med huvudmålet att det ska vara ganska enkelt att emulera. Ju mindre kringutrustning som ska emuleras, desto bättre. mindre quirks och buggar som behöver replikeras, också desto bättre.

Låter som ett bra försök. Och ännu viktigare tar det bort några till synes enkla system (som singleboarders) från listan, eftersom de förlitar sig på komplex hantering av I / O-enheter (som realtidsåtkomst till portar för att driva LED-segment på till synes kontinuerligt sätt).

Jag vill utsätta eleverna för de viktiga begreppen assemb språk, instruktionskodning, adresseringslägen, CPU-register, minneskartade maskinvaruregister, etc.,

Något som kan göras med en riktig hårdvara som samt en emulering, är det inte?

Helst bör systemet i fråga inte kräva cykelnoggrann emulering eller knep som att jaga skanningslinjen.

Tillsammans med det underförstådda kravet på en videoutgång kräver detta en enkel icke-accelererad bitmappslogik.

Ett andra krav gäller prestanda. Studenterna är verkligen inte bekanta med mjukvaruoptimeringstekniker, så att försöka efterlikna även den första Playstation eller Nintendo 64 kommer förmodligen att stöta på prestandafrågor (kanske till och med SNES och Genesis).

Jag skulle inte frukta mycket här, eftersom PC-hårdvaran är ganska snabb. De verkliga problemen här är inte emuleringshastighet utan aspekter i realtid – synkronisering av olika emuleringsdelar – som kräver en mycket noggrann och finjusterad programvarudesign. Inte att förväntas här. Ganska den ”racing the beam” -delen du nämnde.

Vid den här tiden behöver eleverna bara vara oroliga för att implementera emulatorn korrekt, inte effektivt. CPU-emulering kommer säkert att implementeras av en tolk, inte en översättare / recompiler.

Fortfarande, även för de mest primitiva, är realtidssynkronisering nödvändig för spela ett spel. Åtminstone en synkronisering av skärmspårning är ett måste – inte åtminstone för att snabbt växla simuleringen själv.

Det inneboende behovet av spel för att använda tidseffekter – och synkroniserad skärmmanipulation på en finare nivå än ramar – är något som kommer att göra att köra alla riktiga spel på den föreslagna emulatorn till en utmaning.

Jag skulle vilja välja ett system som spel gjordes för, även om nämnda system inte var en dedikerad videospelkonsol. Jag känner att det skulle vara mycket motiverande för eleverna att kunna köra spel på emulatorn.

Jag håller helhjärtat med här. Mycket av framgången för Andre LaMothe s experiment- och inlärningssystem bygger på den främsta förmågan att göra spel.

Till exempel, just nu tittar jag på NES, men det känns fortfarande lite komplicerat, särskilt PPU. Finns det enklare alternativ?

Det blir svårt eftersom de grundläggande kraven strider mot varandra. Bara framgångsrika konsoler / datorer fick ett stort urval av spel, men dessa är också sådana med en mer komplex hårdvarustruktur som möjliggör fantastiska spel.

Låt oss kolla några välkända system. Jag skulle vilja separera dem i ”enkla” och ”komplexa” system längs komplexiteten i deras videologik (* 1)

Enkla system

I första iteration är detta alla system utan dedikerad VDC / CRTC.

• Atari VCS – så småningom det ultimata systemet som ska användas för att lära sig monterare, arbeta på en extrem grundnivå utan mellanliggande och inte mycket att ta hand om. Samtidigt ”namnet på termen” racing the beam ”.

  Med detta sagt kan det fortfarande vara ett system att leta efter, eftersom de tidsberoende delarna är väldefinierade och (jämfört med någon annan video) extremt enkelt och lätt att efterlikna – förutom att det inte är nybörjare. Det är också extremt väldokumenterat på allmänt tillgängliga källor.

• Commodore PET – Ett ganska enkelt system, speciellt eftersom hela videodelen kan emuleras ganska abstrakt, ändå måste VIAs åtminstone delvis emuleras. Viktigast innehåller den bara två tidskällor (bredvid klockan).

  Ett bra plus för PET (och uppföljningar) är den goda dokumentationen (också på grund av dess enkelhet). Även om den har en CRTC, används nästan inget spel (eller annan programvara) omprogrammering alls, vilket gör det enkelt och en ofullständig (abstrakt) emulering möjlig.

  På baksidan finns det endast ett ganska litet antal spel och de flesta av dem är skrivna i BASIC, vilket kan kräva lite forskning för att hitta mängden abstraktion mot detaljer i emulering.

• Apple II – Återigen, ett otroligt väldokumenterat system med massor av programvara. Mycket av det monteringsbaserat. Medan hårdvaran är helt dokumenterad och byggd av endast TTL är den inte riktigt enkel och eftersom vissa spel starkt förlitar sig på quirks och räknar loopar för exakt timing kan emulering bli mycket mer komplicerad än antagen vid första anblicken. p>

  Ett plus för dig kan vara att Apple II var ganska populärt i Brasilien (bra då).

• TRS-80 – Även här videologiken är uppbyggd från TTL men mycket enklare än på Apple. Liknande annan I / O är ganska enkel. På den negativa sidan är återigen ett ganska litet antal spel.

Hittills kan de verkliga forntida, men också vissa senare system klassificeras som enkla:

• Sinclair Spectrum – Medan logiken ger några knep, visslar klockor &, men det är en rakt fram kaklad bitmappsdesign. Hittills är chanserna bra för en emulering, förutom att spel som vanligt förlitar sig mycket på timing, något som komplicerar emulering igen.

  Liksom med Apple II, där det var en del kloner i Brasilien .

• Ett liknande fall kan göras för ORIC-familjen

• Atari ST – Det kan vara en överraskning från dagens punkt men Atari ST hade ingen sofistikerad videohårdvara. Bara tre grafiska upplösningar och en 9-bitars CLUT för upp till 16 färger samtidigt. Några synkroniseringspunkter och en enda timer. Plus en modernare CPU och ett dedikerat ljudchip. Låter som en match som gjorts i himlen, om det inte skulle vara för programmerare av spel igen. Även här innebar programvara en hel mängd knep för att skapa fantastiska spel (* 2).

En första slutsats för ”enkla” system är att även om hårdvaran kan vara mindre komplex, så gick programvaran mycket långt för att övervinna detta. Följaktligen kan den kanske sägas att mindre komplexa system inte nödvändigtvis gör en emulering mindre komplex, eftersom inte mer olika hårdvara ska emuleras, men den enkla hårdvaran måste följas mycket nära timing för att få befintlig spelkod att köra.

Komplexa system

Dessa är i allmänhet alla system med en sofistikerad VDC

• 9918 ff .- Det här handlar inte så mycket om ett enda system, men så småningom den vanligaste VDC (TI kallade den VDP). Medan den var utformad för TI 99/4 sålde TI den till alla som var intresserade. Det resulterade i majoriteten av alla system (* 3) som använder en 9918 eller någon av dess uppföljningsdesigner (9928/38/58 / …).

  Spelkonsoler som Coleco Vision , Sega SG-1000 hela vägen till Master System en brunn samt datorer från TI 99/4 eller Memotech MTX hela vägen till hela MSX -världen använde den här familjen.

  Låter bra, eller hur? Det finns säkert många spel att använda. Vidare hjälper en sådan VDP till att förenkla emulering eftersom den erbjuder en tydlig åtskillnad mellan CPU och skärm och begränsar vilka ”trick” ett spel kan använda till vad VDP erbjuder, vilket i sin tur är klart definierat. Och återigen, det är den befintliga programvaran som gör emulering svår, eftersom naturligtvis programmerare naturligtvis använde timingtrick för att manipulera skärmen vid rätt tidpunkt. Nämnde någon ”Racing the Beam”?

• Commodore VC20, C64, C16, etc. – Detsamma gäller för alla Commodores hemdatorer. Även om de skiljer sig i komplexitet genom att ha sprites eller inte, erbjuder timers eller inte och ljud eller inte, är det grundläggande Problemet är detsamma som i 9918-familjen: Programvara som använder vissa tidssituationer för att skapa speleffekter.

• 6847 System – Tandy CoCo, Matra Alice och liknande har samma problem.

Jag skulle kunna fortsätta med spelsystem som NES eller MegaDrive, men jag avslutar listan här, eftersom principen bör vara tydlig nu: Även om vissa system kan vara som mer komplicerad att emuleras, är det verkliga problemet inte komplexiteten i videohårdvara, men när en programmerare ”förbättrar” vad kan man göra med smart programmering (* 4). Så det verkliga problemet för ditt projekt är inte (så mycket) hårdvaran (* 5), eftersom det är mjukvaran, speciellt de knep och verktyg som används i riktigt existerande spel .

Det är särskilt dåligt, eftersom du vill använda (som jag läser det) befintliga spel som motivation. Det kommer inte att vara många som kör på en mindre hård realtidsemulering.

Att minska detta beroende minskar antalet spel som körs korrekt. Att reducera den till en nivå som gör att den kan hanteras i en tidsbegränsad kurs gör det nästan omöjligt att hitta lämpliga spel.

Slutsats: Hitta rätt avvägning är ett sätt, men ett som kommer att kräva betydande undersökningar samtidigt som användbarheten begränsas.

---

Nu är det kanske möjligt att attackera detta från en lite annan vinkel. Låt oss prova några:

• Användning av befintlig gammal hårdvara:

  Även om detta är bevisat (* 6) fungerar det, erbjuder högsta kompatibilitet och användarvänlighet på grund av öppna utvecklingsmiljöer, kan det missa ”build” överklagandet för EE-studenter.

• Använd befintliga utbildningssystem:

  System som Andre LaMothe ”s XGS är fantastiska verktyg för att dyka in i detaljerad hårdvarubyggning och programmering. Visst, lite lödning krävs (det finns färdigbyggnad tillgänglig), de är nästan fullständiga programvarudefinierade system, genomgående dokumenterade och erbjuder ett stort spelbibliotek. För att inte tala om hans böcker om spelprogrammering.

  En bra bonus är att studenter kanske kan ta systemet hem och spela även efter att kursen har avslutats.

• Bygg ditt eget enkla system:

  Ta en klassisk CPU (till exempel 6502), lite RAM, FLASH och en VIA plus en FPGA för att implementera en mycket grundläggande CRTC och gjort. Eleverna kommer att löda det, kan lära sig om komponenterna och deras interaktion, inklusive FPGA-användning (vilket kan vara ett måste ändå idag) och sedan köra sin programvara på riktig hårdvara. Även med ett litet antal borde det vara möjligt att producera en sådan bräda runt 50 euro eller mindre. Precis som XGS-idén kommer det att fungera efter att kursen har avslutats – inklusive känslan av ägande som att vara deras system.

  Naturligtvis måste eleverna skriva sina egna spel, men enkla spel kan göras på ganska kort tid – för att inte tala om att uppföljningskurser lika gärna kan använda spel som den tidigare klassen skrev.

• Gör en emulering av ”ditt eget” system

  Liksom tidigare, förutom att allt är virtuellt. Det fick fördelen av att vara en brunn definierat och stänger system, särskilt ett där det inte finns några begränsningar för en mindre ”perfekt” emulering – Emuleringen är perfekt per definition och alla dess karaktärer är den som systemet har. Nackdelen är återigen programvarudelen.

• Använd ”mjuk” maskinvara:

  Det finns ett projekt av Neil Franklin som skapar ett antal generaliserade systemkomponenter som klassiska datorer hade, men med hjälp av mikrokontroller istället för dedikerade marker. Den kombinerar emulering med riktig hårdvara. Medan komponenter fortfarande utvecklas som emulering, är dessa avsedda att köras i en mikrokontroller och användas ungefär som ”riktiga” chips. Ett system kan ställas in med hjälp av en SoftCPU-modul som emulerar till exempel en 6502 med lite RAM och ROM, kombinerat med en SoftVGA som levererar en terminal som ett videogränssnitt och ett SoftPS2-emulerande tangentbord och mus. Alla är anslutna via en parallell eller seriell (SPI) buss som möjliggör tillägg av andra komponenter som också kan presenteras för emuleringen.

  Förutom att allt handlar om emulering, har den en begränsad mängd hårdvara som kan göras på en bräda (ändå är det aldrig för tidigt att börja löda), det visar också en ganska typisk uppgift för dagens teknik – att ersätta traditionell logik med mikrokontroller – i praktisk användning.

  resultatet är ett system som ger touch och känsla av en riktig (gammal) dator medan den byggs med modern hårdvara som kör parallella emuleringar.

• Användning av en konfigurerbar emulator:

  Nej, det här handlar inte om MAME eller liknande, utan ett emulatorram skrivet i JavaScript som hanterar de generiska delarna (inklusive timing), där dina elever kommer att lägga till sina emuleringar (vilket var ett mål, var det inte?) för att bilda ett helt system. Eftersom JS levereras i källan kan även själva Framework modifieras.

  Beroende på kvaliteten på varje emulering kan detta vara användbart för allt från ett enkelt demonstrationssystem till en fullständig rekreation av 1980-talet dator.

Så kanske några av ovanstående variationer kan vara en bra start?

---

* 1 – Jag fokuserar bara på video (och CPU) för att hålla det enkelt. Även enbart video fungerar redan bra för att rensa bort kompletta system. Ljud kommer att lägga till ytterligare en dimension och kan komplicera det långt utanför detta.

* 2 – Titta bara på Xenon. En banbrytande vertikal scroller med flera skiftande lager många animerade objekt, alla körs supermjuk i programvara. Faktum är att den var så finjusterad att det att ta en port till den (vanligtvis) mer kapabla Amiga (grafikmässigt) tog ganska lång tid och resulterade i ett något mindre spel.

* 3 – System konstruerade inte nödvändiga enheter sålda. Sedan igen, några spelkonsoler var mer än bara framgångsrika, så det kan till och med få majoriteten i antal.

* 4 – Blogginläggen för huvudutvecklaren av Glide64 renderar-plugin för N64-emulatorer har skrivit en serie med flera delar ( Intro , P .1 , P.2 , P.3 ) av blogginlägg om hindren han var tvungen att klättra för att få videoemuleringsdelen att fungera – alla handlar inte om komplexiteten i att emulera hårdvaran, utan alla sätt som CPU modifierade och justerade utdata bredvid videologiken. Detta är ännu mer anmärkningsvärt med tanke på att N64 redan är ett ganska absurt och slutet system.

* 5 – Jag skulle faktiskt vilja betrakta mer komplex videohårdvara som en bra lektion för EE-studenter, eftersom det väl visar vad kan göras med några grindar istället för högar med mjukvara – ännu mer eftersom de håller på att göra hårdvara senare, är det inte?

* 6 – Stefan Höltgen vid FU Berlin använder till exempel gamla spelsystem i sina klasser för att introducera (icke-EE) studenter till riktig hårdvara och verklig programmering och deras implikationer för dagliga uppgifter (och spel).

Kommentarer

• @Tommy Tja, jag skulle gärna undvika detta, eftersom det inte finns något enkelt svar. Det viktigaste här kan vara, att medan Z80 är något ” knäppa ”, 68k är allt annat än enkelt. Med alla tilläggsord (upp till CPU32) kan en enda instruktion ha upp till 11 ord (22 byte) och avkodning är en allvarlig röra. Sedan beror allt på hur emulatorn består. Z80 är en ganska rak framåt 8080, lätt att emulera, med några modifierare, som lätt kan hanteras. För 68k, även den ursprungliga, blir det mycket mer arbete.
• ” uppgift som passar för nybörjare på så begränsad tid. ” Han sa att det här är tredjeårsstudenter, inte nybörjare, och de ’ har redan slutfört flera förutsättningar.
• @ wizzwizz4 Tja, oavsett vad vår personliga åsikt är, är JS den lagliga arvtagaren till BASIC. Allvarligt och på alla sätt! Tänk på det.Det körs inte bara n bredvid varje faktisk dator, det ’ är till och med installerat som standard, och det finns nästan inget sätt att bli av med det utan att förlora mycket funktionalitet. Ännu mer, tänk bara på hur mycket dålig och otrolig långsam programvara som skrivs i JS – det perfekta beviset, är det inte ’?
• @Raffzahn Det ’ är helt annorlunda För det första hade BASIC flera inkompatibla implementer … Ohhh! Det är efterträdaren till BASIC!
• De ’ är fortfarande inte nybörjare, som är förstaårsstudenter. Och jag tycker att du borde ge OP den fördelen av tvivel om att han inte ’ t skulle tilldela projektet om eleverna inte ’ t har önskad bakgrund.

Det finns några bra idéer hittills.

Men något att tänka på.

Om du gör något som en CP / M-maskin är de egentligen ganska grundläggande och enkla, speciellt eftersom allt inte bara isoleras av BIOS utan också av IN / OUT-naturen av 8080 / Z80-familjen.

Det verkar inte vara olämpligt för mig att ha en CP / M-maskin som är målet för den första terminen. (Jag känner inte till din kursplan)

Men, till exempel, en grundläggande CP / M-maskin behöver inte cykelnoggrannhet, den behöver inte avbrytas, det mest komplicerade det måste göra är att undersöka tangentbordet för att se om en tangent har tryckts. (I motsats till övervakning av nedladdning och tangentborttagning eller något annat.)

Sedan under andra terminen kan du lägga till krav som gränssnitt till ett grafikchip. Exemplet ovan av SG-1000 kunde lätt vara en CP / M-maskin under första terminen och sedan lätt omvandlas till SG-1000 under den andra (eftersom du har gjort Z80-delen klar under första terminen) .

Slutligen tror jag att det krävs för din klass att ha ett godkännandeprogram som eleverna kan köra för att verifiera sin CPU. Få saker mer spännande än att felsöka en dålig CPU, särskilt med maskinspråk som du kanske inte känner till .

6502-communityn har testprogram som kan kontrollera att en CPU utför alla instruktioner ordentligt, jag är inte säker på vad som finns tillgängligt för de andra processorerna.

Och om det är någon tröst i omfattningen, jag skrev både en simulator och en tillhörande montör av och på över en 2 veckors julhelg, om det ger dig någon hjälp med hur stora de faktiska projekten är. Grundläggande processorer är ganska enkla.

Kommentarer

• På Z80 tillhandahåller FUSE tester men inte alla är generiska eller nödvändigtvis korrekta för exakt cykel timing; de ’ finns också i ett ad hoc-textformat men jag ’ har transkriberat dem till JSON: github.com/TomHarte/CLK/tree/master/OSBindings/Mac/… – använd tests.in.json för att ställa in initialtillstånd och ta reda på hur länge ska du springa efter, testa sedan. expected.json för att verifiera resultaten. Det finns ’ också zexall och zexdoc, ursprungligen CP / M-filer men mycket anpassade och mycket långsamma. Att skicka det förstnämnda kräver att en massa odokumenterade saker är korrekta, att skicka det senare inte ’ t.
• … och det enda jag ’ har hittats för 6809, antar att någon tänkte föreslå en Vectrex eller Coco / Dragon, finns i en bredare Williams arkadmaskintestsvit på seanriddle.com/wetsold.html . För 6502 är jag väldigt mycket ombord med testerna från Klaus Dormann, Wolfgang Lorenz och AllSuiteA, som alla verkar vara mycket mer framträdande än Z80- eller 6809-testerna.
• @Tommy Så långt som Jag är ’ medveten om att alla Fuse ’ -tester är korrekta. Vänligen arkivera buggar om de ’ inte är 🙂
• @PhilipKendall se mitt e-postmeddelande den 29/5/2017 för att smälta-emulator-utveckla re: DJNZ och om offset läses på en slutlig iteration. Slutsats från Alan Cox om FUSE ’ s testade beteende är korrekt var att det ’ s ” öppen för tolkning ” baserat på tillgängliga källor. Så jag tyckte att ” inte nödvändigtvis var korrekt ” var rättvist. Jag borde antagligen ha varit tydlig: jag hittade bara en handfull avvikelser i ditt team ’ tolkning av bevis och min egen. Ber om ursäkt för dålig form på det.
• @Tommy – ” Slutsats från Alan Cox om FUSE ’ testats beteendet är korrekt var att det ’ s ” öppet för tolkning ” baserat på tillgängligt källor ” …medan jag har mycket respekt för mycket av vad Alan gör är det ’ ganska enkelt att verifiera om det testade beteendet är detsamma som en faktisk Z80-processor (särskilt för CMOS-versioner som kan köras på brödbräda med låga klockhastigheter för att ställa in detaljerade tester mycket enkelt), så det här är definitivt ett fall där om han tycker att det ’ är något fel han borde vara kan visa det mycket enkelt.

Kan jag föreslå SG-1000 ?

Systemet är lite mer än en gruppering av tre hylschips – Z80, TMS9928A för grafik och SN76489 för ljud, med kontrollerna som dumma grupper av NO (normalt öppna) switchar.

I programvara eller hårdvara kan du simulera eller emulera någon del av detta isolerat eller tillsammans för att producera hela systemet.

systemet använder enkla icke-bankomkopplade ROM-skivor för sina spel, och de brukar användas y lita inte på några knep som avbrott i mitten av skärmen eller cykelräkning för att få effekterna. Bara en enda kakelkarta och ett antal sprites på toppen. Jag föreslår att detta är mycket enklare än ett system som innehåller många interagerande interna komponenter och intelligenta patroner som NES.

Du borde ge dina egna spel att efterlikna snarare än att distribuera olicensierade naturligtvis upphovsrättsskyddat material.

Kommentarer

• … och för att säga till detta är ColecoVision exakt samma samling komponenter, med olika anslutning logik och mycket lite mer komplicerade joypads. Så en SG-1000-emulator är vanligtvis lätt att utöka för att stödja båda.
• Det är också anmärkningsvärt att 9918 är ett komplext chip med sprites, komplexa modi och data, som han inte gjorde ’ vill inte använda. Är det inte ’?

Ett enkelt, enkel dator som ZX Spectrum låter rimligt – Men det finns helt enkelt för många bra emulatorer redan för att göra detta till ett användbart alternativ. Jag tycker också att 6502 är lättare att emulera.

Så, ett möjligt alternativ kan vara Oric-1 eller Atmos by Tangerine-system , som använde ett 6502, icke-bankminne, inga anpassade marker förutom enkel video och en relativt enkel bildbuffert. Det är också överlägset inte så känt som Spectrum, men det finns fortfarande programvara (spel) tillgänglig för att ta med några enkla kompatibilitetstest (jag tror att en viss ”känsla av prestation” är oerhört viktigt för studenter). Det finns ett antal emulatorer som redan finns tillgängliga för Atmos (tre, såvitt jag vet), men deras antal är begränsat, vilket gör det enkelt att ta reda på om någon lurade och helt enkelt kopierade koden.

Ingen av Oric-spel var så sofistikerade såvitt jag vet att du skulle behöva en 100% cykelexakt emulering för att köra spelen,

Kommentarer

• I ’ d hävdar att Oric-arkitekturen avskräcker rasterracing genom att inte ha en sidokanal med videokontrollregister och inte är inställd så att racing tänkbart kan öka din färgupplösning (kontrasterat med ett spektrum). Om det bara hade två HIRES-buffertar, sa jag ’ d mer tryggt. Skulle du hålla med det?
• @Tommy I ’ Jag är inte så bekant med Oric-videokretsarna. Vad jag i alla fall skulle säga är att Oric hade så kort livslängd och en så begränsad användarbas att sofistikerade tekniker för att finjustera videon som vi känner till från ZX Spectrum inte ’ t utvecklat (åtminstone inte under datorns aktiva livstid, där ’ ett antal intressanta demos här demozoo.org/platforms/ 49 )
• Åh, då ger jag ’ bättre resonemang: Oric-videokretsen har ett modalt tillstånd, inklusive text- eller grafikläge, men inget exponerade register. Allt ställs in av kontrollbyte i videoströmmen – inklusive förgrunds- och bakgrundsattribut. Människor tenderar att klaga på det för att det betyder att om du vill ha gaplös grafik är du ’ begränsad till fyra färger per rad, varav två är bitvis komplement till de andra två. Några av de moderna spelen ser fortfarande riktigt bra ut – t.ex. Stormlord youtube.com/watch?v=QSDy-BC580M
• @Tommy Serialattributen gör programmeringen lite mer knepig, jag ’ gissning, men mängden attributkollision är ännu bättre än på ZX Spectrum, tror jag.
• Xenon 1 behöver cykeln exakt, annars låser det sig när fartyget exploderar (ansvarsfriskrivning: Jag skrev en oric-emulator för amiga som heter amoric och snubblade in i denna fråga, men bara i det här spelet)

Baserat på dina kriterier och behovet av att hålla projektet intressant för dina studenter rekommenderar jag överväger allvarligt Vectrex Arcade System, som såldes av Milton Bradley i början av 1980-talet.

Eftersom Vectrex är unikt när det gäller att använda en vektordisplay snarare än en rastervisning, gör den inte kräver att komplicerad videohårdvara ska emuleras. Displayen hanteras av CPU: n och själva bildskärmen är enkel att emulera på ett modernt system och med god prestanda.

Förutom att emulera vektordisplayen är CPU ( Motorola 6809) och I / O-chipet (MOS 6522) representerar inte för muk h av en utmaning eftersom de är enkla 8-bitars delar som är väldokumenterade.

Minnemodellen är också väldigt enkel utan några banksystem som jag känner till. Det finns ett vanligt PSG-ljudchip i Vectrex, men att emulera det kan betraktas som ”Extra Credit”.

Till skillnad från andra enkla spelkonsoler från början av 1980-talet har Vectrex-spelen hållit ganska bra, givet dess förmåga att göra jämn monokrom grafik inklusive 3D-trådram. Detta framgår tydligare av populariteten hos den moderna ”home brew” -utvecklingen, där utvecklare fortsätter att skapa nya Vectrex-spel.

En sista fördel för Vectrex är att det ursprungliga systemet ROM är fritt distribuerbart.

Kommentarer

• Förutom att vectrexen också fotar väl ’ Racing the Beam ’ cathegory, inte ’ t det?
• @Raffzahn, som jag förstår det, styr Vectrex CPU elektronstrålen – exakt motsatsen till en ” som strålar strålen ” där programvaran behöver göra exakt tidsinställda tillståndsändringar till fortsätt med en externt tidsinställd rasterskanningsdisplay.
• @Mark Det är ’ samma sak med VCS. Även här styrs strålen av CPU: n. Utan att CPU har åtkomst till WSYNC varje rad och innan raden är klar kommer skärmen att vackla. Och så vitt jag förstår OP, handlar det ’ om att inte återskapa ett system med strikta tidskrav – vilket är viktigt för Vectrex.
• @Raffzahn: Processorn i VCS styr vertikalen, men den kontrollerar inte den horisontella. Det ’ är inte ovanligt att ett spel matar ut dussintals eller till och med hundratals skanningslinjer utan en intervenerande WSYNC. I avsaknad av en WSYNC kommer strålen att vara i samma horisontella läge var 76: e cykel. Att lagra WSYNC är ofta det enklaste sättet att vänta på att strålen når den högra sidan av det visade området, men det är ’ knappast det enda sättet. En programmerare som var så benägen kunde utnyttja de komplicerade detaljerna i sprite-rörelse och beteenden för att skriva ett spel som aldrig använde WSYNC alls.
• Um, folkens, vi pratar om en emulator här. Det kommer inte att finnas ett problem med att fosforerna bleknar medan den emulerade CPU tar för lång tid att rita nästa bild. Det finns ingen ” stråle ” och det finns verkligen ingen anledning att emulatorn skulle behöva ” race ” eftersom emulatordisplayen förblir ganska statisk så länge som det behövs mellan ramarna.

Att skapa en emulator från grunden är relativt stor uppgift, särskilt för oerfarna studenter och kan vara problematisk. Så du måste verkligen vara försiktig med vilken plattform du ska efterlikna och vilken information du ska dela / använda. För mig är det bästa valet en ZX 48K-plattform eftersom jag växte på den och känner till dess inre funktion så svaret kommer att vara partisk av det … Men vi måste komma ihåg att studenter idag vanligtvis inte såg / använde / visste det så mycket som vi gör … Vad du behöver uppnå är:

1. korrekt CPU-isetemulering

   även om det finns massor av instruktionsuppsättningar dokument där ute Du måste vara försiktig eftersom till exempel på Z80 innehåller 99,99% av dem misstag. Så du bör välja en testad referensis för dem, nu är den korrekt (eller åtminstone basisk funktionell).

   Till exempel här är min Z80 iset som passerar ZEXAL med 100% framgång:

   • min Zilog Z80A komplett instruktionsuppsättning med maskincykeltiming

   Z80-plattformen har en stor fördel och det är att det finns omfattande testare för det som ZEXALL Tränare som kan hjälpa till att felsöka emulatorn mycket.

   Jag tror att det också finns versioner för i8080 men jag känner inte till några sådana testare för olika CPU-familjer.

2. Timing

   väl för grundläggande emulering är det nog med klocktics-metoden (eller strypning) vilket är välkänt och använt … Jag ser inget problem här. Numera har datorer relativt bra upplösning för timing (på PC: RDTSC, på Windows PerformanceCounter, …).

   Den grundläggande emulatorn kan ignorera INNEHÅLLET på den emulerade plattformen men se upp för vissa OS / spel / appar kan göras oanvändbar om den inte emuleras ordentligt. Detta gäller inte bara för demos. Den vanliga tidpunkten på gamla datorer härleddes från en del avbrott (vanligtvis videouppdatering) och ett begränsat antal cykler där de kunde utföra innan den. Men med påståendet kan antalet instruktioner som utförs under samma tid vara väldigt olika och vissa program kan rinna över och skada dem själva eller frysa. INNEHÅLLET är det svåraste att implementera med klocktics så du bör undvika det till varje pris … Å andra sidan med MC-nivåinställningar är det väldigt enkelt och bara några rader kod.

3. Ljud

   detta är plattformsberoende problem och du bör välja det API som används för ljudingång / utgång korrekt. Till exempel på windows är det enda användbara alternativet WAvEIN / WAVEOUT på grund av låg latens och enkel användning. DirectX är oanvändbart (åtminstone var jag försökte använda den för en sådan uppgift) på grund av HÖGA latenser och inte fungerade återuppringningar.

   Jag skulle använda buffrad metod istället för direkt högtalarkörning så att din emulering kan spränga exekveringstiden istället för MC-nivå korrekt körning (vilket jag ändå gör men jag tvivlar på att eleverna skulle kunna göra det under den aktuella tiden).

4. Video

   Den här är också plattformsberoende. .. och du bör använda API som dina elever känner till. Även strålspårning är relativt lätt att implementera med enkel bitmapp … På datorer som ZX har Scanline-ordningen speciell betydelse och kan vara mycket distraherande för nybörjarkodare, så det är bättre att använda översättnings-LUT-tabeller som omvandlar mellan adress och y-koordinat fram och tillbaka.

   De flesta äldre plattformar använde 50Hz / 60Hz uppdateringshastighet och relativt liten upplösning så nuförtiden bör datorer även med inte väl optimerad emulering fortfarande vara tillräckligt snabba för det. Om inte Hoppa över ramar är också ett alternativ …

5. övrig HW och kringutrustning

   Det absoluta minimumet är RAM / ROM-minne och tangentbord. Minne är vanligtvis väldigt enkelt, bara statisk matris och eller några sidväxlar … Tangentbordet kan emuleras genom att ställa in I / O enligt de tangenter som trycks ned. I / O kan också minnesmappas till någon matris precis som minne. Att fånga ISR-rutin är också ett alternativ, men det gör tangentbordet oanvändbart för anpassade nyckelhanterare.

   Jag skulle inte bry mig om FDC, AY, etc. kringutrustning eftersom emulatorn bör hållas så enkel som möjligt. Men om du har tur kan det finnas några studenter som kommer att vara långt före andra med detta projekt. För dem kan du föreslå att implementera spännande funktioner som FDC, DMA, till och med riktigt ljudkort (för riktiga band eller andra ljudspelare) som möjliggör mycket fina funktioner till exempel se:

   • Z8410 DMA-chip som GPU?

6. Filer

   Jag skulle gå för Z80 / SNA-filformat vid start. Att använda TAP / TZX är trevligt, men från början skulle emulatorn vara ganska buggig, därför kan det hända att laddningsrutiner inte fungerar ordentligt, vilket gör det svårt att använda och felsöka.

7. ROM

   detta är den mest problematiska delen eftersom många ROM-plattformar fortfarande inte är gratis och genom att extrahera / ladda ner / använda dem för emulering kan du riskera juridiska problem.

   Från vissa kommentarer här ser det ut som att ZX-ROM är allmängods nu … och det finns också kommenterade ROM pri nts där ute vilket gör det mycket lättare att felsöka de första stegen i emulatorn (när ingenting ännu fungerar).

   Men du bör alltid överväga Emulering och lagliga grejer speciellt om emulatorerna placeras någonstans på internet

Här några relaterade QA-länkar av mig:

• Hur man skaffar CPU och andra hårdvaruspecifikationer för emulatorutveckling
• Skriva en grafisk Z80 emulator i C eller C ++ Jag rekommenderar starkt att läsa den här (speciellt för dina elever) kommer att spara mycket tid och nerver
• Vad är rätt implementering för maskinvaruemulering?

Letar du efter en system som inte har emulerats mycket? Jag föreslår att du håller dig inom 8-bitars datorer (eller tidiga enkla 16/32 bitars), ZX Spectrum 48k är ett så relativt enkelt system – väldokumenterat, inga sprites, inget ljudchip, inget RAM-banker, enkel I / O, si Mple grafik (men med en konstig layout), ingen cykel perfekt emulering krävs, välkänd CPU, enkel kassetthantering (kan göras ännu enklare med ROM-fällor). Det finns ton spel, många av dem med tillåtet licensiering.

Nackdelen: det finns en enorm mängd tillgängliga emulatorer, många själva retrokategorin, och många med källkod tillgängligt, så risken för fusk och kopiering av annan kod är hög.

Och naturligtvis skulle arbete på en emulator av ett tidigare inte emulerat system ge ytterligare fördelar av känslan av prestation.

Kommentarer

• Jag hade samma instinkt, men skulle förlänga genom att föreslå att SNA och Z80 och tillräckligt väl definierade ögonblicksbildformat som du behöver ’ oroa dig inte ens för bandemuleringen. Och låt ’ vara ärliga, TZX är lite av en miasma vid denna tidpunkt.
• Jag tror att Spectrum ROM nu är i det offentliga området, vilket kan hjälpa (eller göra saker för lätt)
• ZX Spectrum är ett utmärkt exempel på enkel hårdvara, men också en av ganska komplexa, cykelräkning (Racing the Beam) programmering för att få ut användbara speleffekter.
• @Tommy Åh, jag skulle aldrig föreslå ZX80 / 81 av samma anledning. Och även om det inte är en riktig Spectrum buff, har jag sett en bra timingberoende kod för det. De flesta prominet skärmmanipulationer efter den delen har visats, men innan den körs en gång. Det ’ är en mycket enkel fråga som finns på en hel del system. Inget stort problem, men tidsberoende. Till exempel enkla emuleringsscheman som bara stryker hastigheten på ramnivå ger skit på snabbare emuleringsvärdar … och så vidare.
• @Stormcloud Spectrum ROM är inte offentligt, även om tillstånd har givits beviljas för att distribuera den för användning med emulatorer. ZX80 och ZX81 ROM har släppts under GPL.

Får jag föreslå att titta på några tidiga arkadspel? Specifikt dessa två 8080 / Z80-plattformar:

• Midway 8080 – Utvecklades 1975 och driver Space Invaders . Använder en 256x224x1 bit svartvit rambuffert i RAM.

• VIC Dual – Sega / Gremlin ”s plattform designad 1977 – det mest kända spelet är Carnival . Videon är en 32×28 uppsättning med 8×8 tecken (alla i RAM) och kan stödja en enkel färgpalett, mappad till PROM.

Dessa är väldigt enkla att emulera när Z80-emuleringen fungerar. Det finns inga roliga scanline-trick eller konstiga CPU-väntelägen. kontroller är tillgängliga via bitmappade I / O-portar.

Du kan spela med dessa plattformar interaktivt på http://8bitworkshop.com/ (Fullständig information: Jag driver den här webbplatsen och är författare till de böcker som länkas på webbplatsen som beskriver dessa plattformar)

Apple] [är också ett bra val för en 6502-baserad plattform, även om videosubsystemet är mer komplicerat än i de två arkadplattformarna.

Kommentarer

• För vad det ’ är värt, jag tycker att Space Invaders är ett inspirerat förslag. Om minnet serverar det ’ är det bara en 8080 med en bitmappad skärm på 1bpp, en port IO för kontrollerna, inget försök att tävla med raster, ljud som bara är av formen ” utlöser brus X nu ”, mycket avslappnade noggrannhetskrav, och det producerar ett spel som de fortfarande ibland försöker sälja nu. Det ’ är bara legalitetsfrågan som kan ge paus, även om jag ’ alltid är oskarp på akademiska undantag.
• Att ’ är ganska rätt, det finns ’ också ett externt chip som hjälper till med 8080 ’ saknar en tunnväxlare. Det borde inte finnas ’ något legalitetsproblem som emulerar hårdvaran (det finns ’ inget upphovsrättsskyddat BIOS eller annan kod) och det ’ är ganska lätt att skriva ditt eget spel, t.ex.: 8bitworkshop.com/v3.2.0/?platform=mw8080bw& file = game2.c

PET eller TRS80 kanske fungerar väl. Enkel maskinvara med text på skärmen så att de kan emuleras med rak text. Utgångspunkten lägger till kod för sina udda teckenuppsättningar senare och kommer sannolikt inte att innehålla mycket i vägen för exakt kodräkningskod.

Bonusidé om gå till ett PET-tillägg av C64-stöd skulle ge grafik.

6502 är förmodligen enklare att efterlikna.

Slutlig tanke kan vara Ohio Scientific Superboard II eller i UK: s inkarnation UK101 eftersom jag inte tror att den har omprogrammerbar videohårdvara.

Kommentarer

• Ja, alla tre (PET, TRS, Superboard (jag glömde helt om den senare)) är fantastiska enkla maskiner och bra för emuleringar. Men saknar också ett bra urval av färdiga spel. För att inte tala om färg och som folk kan förvänta sig idag.

Digital PDP-8 är en mycket enkel arkitektur som kan vara lätt att skriva en emulator för. Några anledningar till detta är:

• Endast åtta grundläggande instruktioner
• Inget videogränssnitt etc. att emulera, bara terminal I / O
• Inget behov av cykelnoggrannhet, den faktiska serien av maskiner garanterade inte samma beteende över olika implementeringar.
• Kan börja med en enkel installation (t.ex. en 4Kword-maskin som kör FOCAL-69) och gradvis göra emulatorn mer komplex (t.ex. en 32Kword-maskin med utökad aritmetik, som kör OS / 8 från en RK05-skiva)
• Massor av manualer tillgängliga online
• MAINDEC-diagnostiken och deras instruktioner finns tillgängliga online, som kan användas för att testa att emuleringen fungerar korrekt

Detta täcker kanske inte alla dina krav, t.ex. minneskartade I / O, men det innehåller säkert saker som instruktionsavkodning och adresseringslägen. i dokumentationen går helt ner till den grundläggande hårdvarunivån som kan vara lämplig för en EE-kurs.

Kommentarer

• En intressant punkt är att de flesta av de ovannämnda systemen har antingen Z80- eller 6502-processorer, som båda saknas något när det gäller deras adresseringslägen som stöds. Om täckning av adresseringslägen är viktig har PDP-8 ett mycket bättre urval av dem att visa.
• För ” -spelet ” aspekt av frågan, jag tror att Adventure fortfarande upprätthålls / återuppstår för PDP-arkitekturer (men kontrollera att – jag kan ha fel).
• @TobySpeight You ’ är rätt, den upprätthålls eller återuppstår, men för PDP-10 , vilket är helt oförenligt med PDP-8.

ZX Spectrum-alternativet har redan sagt: dess styrka är den helt enkla IO-hårdvaran och det faktum att många befintliga spel INTE kräver exakt, cykel -korrekt emulering av alla quirks med det enda undantaget för ljud (inget i närheten av att korrigera ljud utan cykel-exakt emulering av CPU och korrekt nedprovning av den mellanliggande 1-bitars ljudström som produceras av CPU).

Alla andra alternativ för spelhårdvara som NES, G enesis och alla liknande sprite-baserade maskiner är inte ett alternativ, uppenbarligen, eftersom mycket tid behövs för att lära sig den komplexa hårdvaran, utveckla sätt att emulera den, arbeta kring brister i emuleringen etc. Till exempel till och med ”enkel” Super Mario spel på NES fungerar inte såvida inte sprite kollisionsbit i PPU emuleras korrekt.

De återstående alternativen IMHO är följande:

1. tidig textläge baserad IBM PC
2. någon av de befintliga CP / M-maskinerna
3. (exklusive några ”stora” maskiner före ”mikro” -åra)

Nyckelpunkten här är textlägesvisning, det är inte så svårt att efterlikna och mycket enklare att visa på värddatorn (till och med inget behov av att visa pixelgrafik, arbeta med fönster / SDL / etc.!).

Det behövs emellertid viss utredning för att samla in korrekta program att arbeta med, inklusive spel. Det finns några textlägesspel i CP / M, och det borde också vara några för IBM PC.

Kommentarer

• Med en potentiell fördel med en CP / M-maskin är att det ’ måste vara minst en som bara 8080-emulering kommer att göra?
• Trevligt, men då finns det inte raly många spel för IBM i textläge, är det?
• @Raffzahn – det behöver bara finnas en .
• @Jules Hehehe … ja rätt. Men då säger jag ’ att minst 8080 gör tricket

Antag att det är något bidrag, det här är mina direkta anteckningar om de maskiner som jag har skrivit emulatorer för, i ungefärlig kronologisk lanseringsordning, förhoppningsvis att erbjuda lite färg på filformat, etc:

Atari 2600

Den särskiljande egenskapen hos Atari 2600 är synergin mellan processor och grafikutgång; spel implementeras en realtidsfunktion som levererar grafiska komponenter till videoutgången när rastern körs. Så jag tycker att detta är ett dåligt val för det angivna syftet – det verkliga hårda arbetet med att skriva en 2600-emulator är tidpunkten och samspelet utanför mikroprocessorn.

Apple II

Relativ enkel hårdvara, men väldigt nyanserad, med flera grafiklägen, och du måste köra mot att lära NTSC-video för att kunna avkoda färgutmatningen. Att emulera Disk II är också ganska mycket ett måste, men det är lite av ett uppdrag i sig som de vanligaste filformaten förväntar sig att du tillhandahåller en Apple GCR-kodare.

ZX80 / 81

Också förmodligen alltför komplicerat för det angivna ändamålet, är den centrala tanken att återanvända CPU: s uppdateringscykel och en delmängd av instruktionshämtningar för att skanna video. Om du valde att inte implementera om den mekanismen som originalet, skulle du bara ha ROM-standardtextläget.

Commodore Vic-20

Detta är en vanlig bitmappad maskin med en enkel processor i 6502 och en anständig mängd spel, varav några levererades på patronen, vilket befriade dig från behovet av att emulera ett band eller en hårddisk. Den enda fluga i salvan är dess 6522s; dessa är kombinationstimer / shifter / input / output chips med en hel massa quirks. Men en fin fördel med Vic-20 är att den startar så långt som BASIC-prompten utan att fungera 6522s, och BASIC själv fungerar bara med timrarna för 6522 implementerade , även inexakt.

Dess korta tid som marknadsledare före ankomsten av C64 begränsar också antalet titlar som använder avancerad hårdvara – det finns samtida exempel på rasterracing som Imagic-titlarna , men de är i minoritet.

Filformaten som data bevaras i är en röra , men att begränsa dig till patronstöd och vara försiktig med att bara använda de titlar som levererades på patronen bör undanröja problemet.

ZX Spectrum

Täckt någon annanstans; Jag tycker ett bra val. Speciellt om du håller dig till filformaten för ögonblicksbilder.

Oric 1 / Atmos

Täckt någon annanstans; ett anständigt val, men det finns en annan av de irriterande 6522-talet där inne. De flesta spel finns på band, du måste stödja allt detta.

Acorn Electron

Bitmapped, en 6502 plus relativt enkel extern logik, men sex olika grafiklägen och timing skulle vara ett besvär – kostnaden för varje cykel är en funktion av det område som nås (ROM kontra RAM), grafikläget (40-kolumn mot 80-kolumn lägen) och eventuellt det aktuella grafiska utgångsläget (80-kolumnlägen blockerar RAM-åtkomst under pixelområdet; 40-kolumnlägen inte). Men du kan bara modellera det som en 1Mhz-maskin för de flesta spel och för det mesta komma undan en linjecentrerad version av grafikutdata.

Det finns ett litet antal spel tillgängliga på ROM, men lyckligtvis kommer bandhårdvaran oftast att tillåta en mycket lågkvalitetsemulering: det är likadant som höjer en avbryt vid bytekvitto, med bara två titlar som jag kan tänka mig att göra djupare introspektion än så.

Amstrad CPC

Förmodligen en för att undvika för det angivna syftet – den har en 6845 CRTC, vilket ger mycket konfigurerbar grafikutgång och därför många titlar som tävlar med rastern. Diskanvändning var också ganska genomgripande, men dess 8272-skivkontroller är en helt extra nivå av huvudvärk jämfört med WD1770 som du ofta ser någon annanstans.

MSX och / eller ColecoVision / SG1000

Olika ljudchips, samma CPU och video.Jag tror faktiskt att du kan komma ganska långt och ignorera timing-samspel eftersom videokretsen håller sitt eget RAM på armlängden. Men det är brickor och sprites, och fyra olika grafiklägen, för troligtvis ett alltför stort arbete för en mikroprocesseringskurs.

Master System

Tekniskt sett en förbättrad SG1000, som är allt som maskinen gör plus ett extra grafikläge, men det extra grafikläget är så mycket bättre än de andra att bara en titel använder någonting annan. Så det förenklar faktiskt saker och ting om du ”är glad inom det mesta att ignorera timing.

Men du pratar fortfarande om att ta hänsyn till sprite-prioriteringar, kontrollera kollisioner per pixel, etc. Förmodligen för mycket .

Fotnot: fusk med bandåtkomst

För en massa hemdatorer som nämns ovan kan du faktiskt hoppa över bandemulering för allt som är kodat i standard ROM-format genom att bara infoga en lämplig fälla in i system-ROM och spooling in från källfilen. Många, men inte alla, titlar förlitar sig helt på den inbyggda ROM-skivan för band IO så att det kan få många titlar laddade utan något verkligt försök till hårdvara.

I alla fall är det ett jobb-hack. men det ”gör om den sidan av emulering inte är viktig för dig – du vill hellre ta bort den från ekvationen och ignorera vad som inte fungerar.

Specifikt:

Vic-20:

• om programräknaren blir 0xf7b2, kopiera nästa tejphuvud till den plats som anges av b3: b2, noll ut 0x90 och 0x93 och fortsätt från 0xf7b5 (eftersom du undviker en JSR);
• fälla 0xf90b, kolla efter X = 0xe, om så är fallet hämta nästa banddatakropp och skriv till emulerat minne från c2: c1 men inte längre än af: ae oavsett kroppens storlek, ställ sedan bit 6 på 0x90, rensa flaggorna för bär och avbryt och fortsätt från 0xfccf.

Oric:

För ROM 1.0, fånga datorn på adress 0xe630. För 1.1, se efter adress 0xe6c9.

När du har tagit det, ladda A med nästa byte från bandet och ställ in nollflaggan enligt dess värde.

Sedan RTS.

Det finns också en flagga vid 0x67 på den ursprungliga ROM-skivan, eller 0x24d som skiljer mellan maskinens snabba och långsamma bandkodningar, men det vanliga bandfilformatet har bara de avkodade byten så för en snabb och smutsig emulering oroa dig inte för det.

Elektron:

Installera NOP vid 0xf4e5, 0xf6de, 0xf6fa och 0xfa51 för att inaktivera bandgrenarna. OS kommer nu att försöka ladda banddata som om det vore på en seriell ROM.

Cat PC på 0xf0a8 och kontrollera att X registret är lika med 14 och värdet på adressen 0x247 är noll. Då vet du att ROM försöker hämta nästa byte från bandet.

Sätt nästa byte i Y, ställ A till 0 och RTS.

Det primära bandfilformatet gör det möjligt för dig att spola byte direkt från filen (efter lite trivial bit navi gation och via ZLib eller en annan GZ-dekompressor, men du kan bara skicka i förväg).

ZX Spectrum:

(Den här är transkriberad från mycket gamla anteckningar; det kan vara värt att bekräfta mot en ROM-demontering)

Fånga PC: n som når 0x056c i ROM på 48 kb. Ta nästa block från bandet (om du använder en TAP-fil får du den direkt. Jag skulle hävda att du inte skulle bry dig om att försöka stödja TZX i den här typen av projekt).

Om dess längd är mindre än värdet i DE, återställ bäring och retur.

Jämför blockets första byte med värdet B. Om de inte matchar, återställ bäring och retur.

Annars spolar du de första DE-byten du fick till den adress som IX pekade på och ställde in den låga biten av C och ställde bär.

Gör sedan antingen direkt en RET eller annars hoppar du bara över datorn framåt till 0x05e2, vilket är RET som normalt avslutar bandladdning.

De 128 kb-maskinerna segger in i 48 kb ROM för bandladdning så att samma hack gäller med förbehåll för att kontrollera vad som är sida. h3> Kommentarer

• Trevlig skrivning. Jag håller med om allt sagt – kanske med två små tillägg till Apple II. Även om det är sant att videohårdvaran behöver tänka ganska mycket, dess finess kan fullständigt ignoreras i emulering, som bara ekvivalens för vissa bitmönster måste översättas till färg – om alls, som A2 där det ofta körs med monokrom skärm, med vilken det kan emuleras som vanlig bitmapp utan ytterligare detaljer. För det andra, så länge ädelstenarna som ska spelas är ProDOS-baserade, behövs ingen detaljerad Disk II-emulering, eftersom sådan fungerar med olika hårdvara.
• @Raffzahn vad skulle den enklaste formen av en uppslagstabell för färgutdata vara?Resonera tillbaka från NTSC och behandla allt som nedbrytbart till dubbelt högupplöst, jag kan föreställa mig en tabell indexerad av en tre-bitars räknare som representerar fas plus ett fem-bitars skiftregister för videoutmatning för att få en halv färgcykel med en mittpunkt. Så en 256-post tabell. Men det ’ är mycket naivt resonemang; har människor gjort det bättre?
• @Tommy: Ett enkelt tillvägagångssätt är att helt enkelt använda en upprepande fyrfärgsekvens (jag tror (röd, mörkgul, grön, blå) för dubbla högupplösta pixlar och oskärpa skärmen lite. Det kommer att sluta lämna färgkanter på saker, men riktiga bildskärmar tenderade att göra det hur som helst. Eftersom Apple]

  Svar

  Jag tror att det är möjligt att sträcka eleverna för långt med att använda grafiska spel. Att köra ett spel kräver i allmänhet bra emulering inte bara av majoriteten av processorfunktionerna men också mycket hårdvara, inte minst videokretsarna (som ofta är ganska komplexa och i många fall introducerar en hel del problematiska tidsfrågor). Om något inte fungerar rätt är resultaten sannolikt mycket dis utnämning. Jag föreslår att man börjar med ett enklare mål.

  Jag siktar på ett system som har ett textlägesgränssnitt snarare än grafiskt, eftersom sådana gränssnitt vanligtvis är mycket enklare och kanske inte har några speciella tidskrav som måste uppfyllas (dvs de fungerar ofta helt parallellt med processorns åtkomst till minne utan att påverka processorn alls). Jag skulle också rekommendera ett system som har ett integrerat maskinnivåövervakningsprogram, eftersom detta kan hjälpa till att felsöka program kör på maskinen utan att behöva implementera en felsökare på emuleringsnivå.

  Ett förslag baserat på mitt nuvarande personliga forskningsprojekt är Nascom-datorn. Detta är en relativt enkel Z80-baserad maskin med textlägehårdvara som interagerar inte med CPU: n (om det finns strid, löses det till förmån för CPU: n, vilket innebär att teoretiskt sett en handfull pixlar i varje ram kanske inte visas om skärmen nås samtidigt som uppdateringen är förekommer, men th är sannolikt inte särskilt märkbar eller ens frekvent, så ger ett användbart resultat med mycket enkel hårdvara). Exakt timing är därför troligtvis inte särskilt svårt eller viktigt för denna maskin. Maskinvaran är både enkel och väldokumenterad. Integrerade kringutrustning är en UART (som kan användas antingen för en fjärrterminal / skrivare eller för kassettladdning och -sparing …. vilket innebär att du inte behöver emulera kassetthantering på ljudnivå, vilket sparar en hel del implementeringstid) och en parallell IO-modul. De tillgängliga verktygen uppmuntrar också experiment på monteringsspråk, vilket jag tror är ett önskvärt mål för din kurs.

  En intressant sak med denna maskin är att det finns en lucka i de tillgängliga emuleringsalternativen: mest kända webbsida om maskinen har begärt en javascript-baserad emulator som de kan bädda in på sidan, men ännu har ingen tillhandahållit en.

  Svar

  Jag har gjort två och lite från början emuleringar för Mac med Swift. Det här är mina personliga observationer baserat på min erfarenhet.

  Ingen av mina emuleringar är helt cykelnoggranna vilket leder till några problem.

  Commodore PET

  Detta var den första emuleringen jag skrev. Du behöver åtminstone en 6502-emulering, en PIA-emulering, en VIA-emulering och en videoemulering.

  6502 är väldigt enkel och en utmärkt processor till att börja med. Det är också ganska väldokumenterat. Visual6502-webbplatsen var ovärderlig för att ta reda på det exakta beteendet för instruktioner där dokumentation var tvetydig. Som en sida skrev jag en emulering av en något senare processor (jag glömmer vilken) som fyllde i en del av luckorna i instruktionsuppsättningen. Detta gjorde det enklare att skriva 6502-testkod (till och med bara PHX och PHY gör vissa saker enklare. På Å andra sidan kommer all programvara som använde de ”odokumenterade instruktionerna” i original 6502 att bryta på min emulering.

  PIA och VIA är relativt enkla IO-chips att efterlikna. Videodrivrutinen kan vara så enkel som läsa skärmens RAM, översätta till ASCII eller en nära approximation och rita den resulterande texten i ett fönster. Så småningom skapade jag en uppsättning bitmappar som var exakta kopior av PET-teckenuppsättningen.

  Min huvudsakliga resurs för PET var ”Programmering av PET / CBM” av Raeto West. Jag har en originalkopia, men det finns PDF-ver sioner online. Viktigt är också tillgängligheten av BASIC och KERNAL ROMS.Du vill inte skriva om operativsystemet.

  Att emulera bandenheten var en PITA. Min mjukvaruversion var mindre tillförlitlig än den riktiga, som PET-ägare vet att verkligen säger något. problemet, tänkte jag, är att det förlitar sig på cykelnoggrann tidspulser och även om min emulator räknar klockpulser, åberopade den inte nödvändigtvis tidavbrottet vid exakt rätt tid. en emulering av de dubbla hårddiskarna. Detta krävde också en robust IEEE 488-emulering, men hårddiskemuleringen var ganska enkel. Det är inte en hårdvaruemulering, det tar bara kommandona som skickas av PET och kör dem med hjälp av platta filer på Mac-hårddisken.

  Till slut skrev jag lite kod som skulle stoppa emulator, injicera en programfil direkt i minnet och starta emulatorn igen. Detta visade sig vara så mycket bekvämare än att emulera skivor eller band som jag slutade arbeta med.

  Min emulator fungerar tillräckligt bra med de flesta PET-koder. Tyvärr finns det ett problem med PET Space Invaders – förmodligen orsakat av tangentbordskoden – så det känner inte igen tangenttryckningar ordentligt. Jag försökte inte heller ta itu med ljudgenerering.

  Sinclair ZX Spectrum

  På vissa sätt är detta ännu enklare än PET. Du måste skriva en Z80-emulator som är mer komplex än 6502 men det finns en CPM-testsvit som du kan använda för att verifiera en hel del av dess funktionalitet, du behöver bara emulera CPM: s karaktärutmatningsundervisning för att göra den fungerande. / p>

  De enda andra marker du behöver efterlikna är ULA och du behöver inte göra mycket av det om du är beredd att avstå från en bandenhet. Även videogeneratorn, som är lite konstig på det sätt som den adresserar skärmens RAM.

  Det riktigt trevliga med Spectrum är att skärmen alltid är i bitmappsläge och OS skapar tecken genom att direkt skriva skrivpixelmönstren. Du behöver inte oroa dig för en karaktärsuppsättning eftersom den magiskt finns där när du startar upp emulatorn med laddade Spectrum ROM-skivor.

  Jag fick Spectrum till den punkt där jag kunde ladda och köra Manic Miner och det var spelbart, om än utan ljud. Det tog ungefär tre månader att arbeta kanske åtta timmar i veckan från början till slut.

  Commodore 64

  Detta är ett pågående arbete. Självklart hade jag redan en 6502, som jag modifierade för att ge mig IO-porten på 6510. Hittills gör det banken byter korrekt, en del av CIA-funktionerna implementeras och tillräckligt med VIC II-funktionalitet emuleras för att ge mig en PET-ekvivalent, dvs. det normala textläget fungerar. Även gräns- och teckenfärgminnet fungerar.

  Jag fortfarande har de mer komplicerade grafiklägen att emulera och sprites och jag borde kunna göra något med ljudet eftersom det är ett separat chip, jag är inte beroende av exakt CPU-timing.

  TL; DR

  Den enklaste emuleringen, förutom CPU: n var spektrumet. Jag skulle nog börja med det, även om en gammal CP / M 8080-baserad dator kan vara ännu enklare om du kan få tag på CP / M.

  Ytterligare observationer

  Du kommer antagligen behöva en bra korsmonterare för din målplattform. Det blir väldigt tråkigt att sätta ihop kod för enhetstester.

  Dessutom kommer en demonterare att vara användbar. Jag behövde inte ta isär Commodore BASIC ROM-skivor eftersom demonteringar är fritt tillgängliga på Internet. Men när jag försökte få Space Invaders att fungera fungerade det inte först och demonteraren var ovärderlig för felsökning.

  Av denna anledning är cc65-sviten ett starkt argument för att börja med en 6502-baserad maskin. Den har en bra monterare och en utmärkt demonterare inkluderad. Z80-situationen var inte så bra, men jag hittade en rimlig monterare som till slut kallades z80asm. Jag tror dock att jag var tvungen att kompilera den från källan.

  Dessutom kommer du att behöva bra solid dokumentation. Återigen är 6502-dokumentationen online praktiskt taget oöverträffad. Dokument är mindre framträdande för Spectrum, men det är så enkelt kan du komma undan med en ganska luddig ULA-emulering.

  Svar

  Tillsammans med alla andra fina förslag, som ett alternativ till Z-80 och CP / M, kan du överväga ett generiskt Motorola 6809 -system för att köra FLEX eller möjligen OS-9 , båda Unix-inspirerade. Som ett CLI-baserat system behöver du inte få någon korrekt timing.

  Dessutom, om du bygger simulatorn är det snarare som att bygga hårdvaran; att porta operativsystemet var en verklig uppgift – som jag gjorde på 1980-talet – i motsats till en klon-något-för-utbildning-uppgift.”Startar det operativsystemet och kör programmen?” är ett mycket realistiskt mål.

  Eftersom det körs ett bärbart operativsystem som körs på många olika tillverkares hårdvara betyder det att eleverna inte bara har ett sätt att göra det. Student A kan bygga en bitkartdisplay; Student B kan skapa en UART och ha ett seriellt gränssnitt. Vissa kanske försöker få varje cykel rätt, andra kanske bara försöker få alla operationer korrekt. Därför istället för att bara försöka kopiera något utan att nödvändigtvis förstå originalet designbegränsningar, eleverna är engagerade i en korrekt teknisk fråga: vad är ett bra sätt att göra detta?

  CPU

  • 6809 var unik vid den tiden genom att det var möjligt att skriva helt positionsoberoende kod, som skulle köra identiskt var som helst i minnet.
  • Instruktionsuppsättningen var nästan helt ortogonal
  • Som en 8-bitars CPU med 16-bitars adressbuss är den ganska enkel
  • Undantagsmekanismen och effektiv -adressmanipulation är mycket som moderna processorer
  • Som en Motorola-design hade den minneskartade IO snarare än speciella IO-instruktioner
  • Lättare att göra än Z-80 (många färre instruktioner ) eller 6502 (färre specialfall)
  • Material via https://en.wikipedia.org/wiki/Motorola_6809

  FLEX designades som ett Unix-inspirerat system för 8-bitars processorer

  • Det var speciellt utformat för bärbarhet, och för att få det att starta krävdes mycket få systemanrop att implementeras – jag tror att bara tecken läsa / skriva, diskett blockera läsa / skriva och någon form av start (läs sektor och hoppa till det).
  • Hårdvaru-agnostiker för dessa grundläggande funktioner, vilket gör simulering mycket mycket enklare
  • Det är spännande att bara skriva några funktioner och starta ett helt operativsystem
  • Ingen grafik att oroa sig över (vilket är positivt eller negativt beroende på din syn)
  • Mycket tillgängligt material, f ind via https://en.wikipedia.org/wiki/FLEX_(operating_system)

  OS-9 liknande avsikt

  • Mer Unix-liknande än FLEX, lite svårare att porta, så vitt jag kommer ihåg
  • Senare överförd till 68000
  • Mycket tillgängligt material, hitta via https://en.wikipedia.org/wiki/OS-9