Nintendo Entertainment System og dets japanske modstykke Famicom behøver ingen introduktion – hvis du læser dette magasin, ved du, at 8-bit hardwaren katapulterede Nintendo til en position som global leder i videospilbranchen og var vært for de første iterationer af utallige klassiske serier.
Selvom marketing spillede en vigtig rolle i denne kommercielle og kulturelle succes, ville det ikke have været muligt uden hardwaren. Når alt kommer til alt, var ColecoVision og Atari 5200 mindre end et år gamle, da Famicom blev lanceret i Japan i 1983, og 3DO og Atari Jaguar var på markedet, da udviklerne endelig opgav NES i 1994. En maskine kan simpelthen ikke forblive relevant i så lang tid uden hardware, der er fleksibel nok og dygtig nok til at følge med gamernes skiftende smag.
Ny grund
(Billedkredit: Evan Amos)Abonner i dag
(Billedkredit: Future)
Denne artikel blev først bragt i magasinet Retro Gamer. Hvis du vil have flere dybdegående artikler om klassiske spil og konsoller leveret direkte til din dør eller enhed, skal du abonnere på Retro Gamer på tryk eller digitalt.
Men NES var ikke kun en titan i sin tid – masser af udviklere skaber nye spil til hardwaren og presser den hårdere end nogensinde med moderne udviklingsværktøjer. To CPU’er og deres derivater dominerede hjemmehardwarescenen i firserne – Zilog Z80, som man så i ZX Spectrum, ColecoVision og Master System, og MOS Technology 6502, som var med i Atari 5200, Apple II og Commodore 64. Nintendos ingeniør Masayuki Uemura valgte 6502’eren til NES, primært fordi den var lille nok til, at en chip også kunne indeholde lydfunktioner.
I 2016 fortalte den afdøde ingeniør til Retro Gamer, at dette valg forårsagede “et kæmpe problem i virksomheden”, da Nintendos hitarkadespil Donkey Kong havde brugt en Z80, og kildekoden ikke kunne genbruges. Hensynet til programmører uden for Nintendo var ikke en prioritet, da virksomheden oprindeligt ikke havde til hensigt, at tredjepartsudgivere skulle være en del af dens forretningsmodel. Selvfølgelig nødvendiggjorde hardwarens succes i Japan og Nordamerika i sidste ende tredjepartsudvikling for at holde trit med efterspørgslen på nye spil.
Systemet havde ikke samme gennemslagskraft i Storbritannien, hvilket er grunden til, at programmøren Paul Machacek ikke stødte på et før 1988, da han sluttede sig til Rare – en af de få britiske udviklere, der koncentrerede sig om Nintendos system. Hans tidligere udgivne spil var skrevet til Z80-baserede computere, og han fik i første omgang til opgave at skrive til det Z80-baserede RAZZ-arkadekort, men han blev snart bedt om at arbejde på et NES-projekt. Heldigvis var Paul bekendt med 6502 assembly-kode fra sin tid som Oric-1-ejer. “Jeg lærte det ret hurtigt igen,” siger han, “men glemte alt om den taljonglering, man lavede på den i forhold til Z80, fordi 6502 har så få registre, men til gengæld havde den hurtige nul-side-lagring.”
Udvikl det, vi gjorde, med de værktøjer, vi havde, på de systemer, vi brugte, og fortæl mig, at du ikke ville ende med at gøre noget lignende.
Paul Machacek
Det udviklingsmiljø, som Paul arbejdede med, var ret simpelt. “Oprindeligt brugte alle hos Rare PDS (Programmers Development System), som var en teksteditor og en kodeassembler. Vi havde hjemmebyggede interfacekort, som blev sat i cartridge-slotten på NES, og de var forbundet med et båndkabel til vores pc’er, som kørte PDS,” forklarer han. “Vi havde ikke noget netværk. Pc’erne var Amstrads med 20 MB (ikke en skrivefejl) harddiske. Hver gang du samlede din kode – det hele blev gjort på én gang, vi havde ikke linkere endnu – blev den fulde binære fil kopieret over båndkablet til interfacekortet, og du kørte din kode på målmaskinen. Som dokumentation havde vi bare standard NES-manualen, som havde et par stavefejl, der skulle rettes, ellers ville tingene ikke fungere, og også din praktiske 6502-instruktionsguide til lejlighedsvis reference, især hvis du ville skrive selvmodificerende kode.”
Hvis du er en programmør, der trækker på smilebåndet over det, bliver det værre. “Der var ingen debug-værktøjer, som man kender dem i dag,” fortsætter Paul. “Der var tricks til at finde ud af, hvor din kode nåede hen, før det gik galt, som at skrive værdier til en hukommelsesplacering og se, hvilken der blev skrevet sidst, før den gik ned, og derefter bruge en halveringssøgning til at indsnævre til den krænkende kode. Til performancetest havde du normalt en visuel ændring på skærmen (forskydning af et vandret scrollregister på skærmen eller ændring af en farvepalet) i starten af en funktion og nulstillede den derefter i slutningen, så du kunne ‘måle’, hvor lang tid det tog på skærmen ved at tegne mærker med tuschpenne omkring denne synlige indikator og se, om mærkerne kom tættere på hinanden, da du fortsatte med at optimere din kode. Ja, folkens, det var dengang, man målte kodeperformance i tommer!”
Det lyder som en ret akavet måde at arbejde på, men Paul ser det bare som et produkt af omstændighederne på det tidspunkt. “Vi gjorde, hvad vi var nødt til at gøre dengang. Folkens, gå 35 år tilbage, udvikl, hvad vi gjorde med de værktøjer, vi havde, på de systemer, vi brugte, og fortæl mig, at I ikke ville ende med at gøre noget lignende!” Heldigvis skulle situationen med tiden blive bedre for Paul og hans kolleger. “Efter et par år hyrede Rare Jon Ritman, en nær medarbejder, til at skrive et nyt system kaldet GLAM [Global Language Assembler Monitor] til at erstatte PDS. GLAM kunne målrettes en bredere vifte af processorer og havde en linker såvel som assembler, så du ikke behøvede at samle hele din kodebase, hver eneste gang du ændrede noget, hvilket fremskyndede udviklingen. GLAM fungerede rigtig godt.”
(Billedkredit: Nintendo)
I sidste ende var 6502-programmering ikke et stort problem for Paul i overgangen til en ny platform. “For mig var den største omvæltning at gå fra hjemmecomputere med bitmappede skærme til NES’ karaktermappede system med separate farvepaletbetegnelser, karakterbanker (og swapping) og memory bank-swapping på carts,” husker han. Nintendos Picture Processing Unit – forkortet PPU – var et specialdesign fra Ricoh, og ifølge Nicolas BÉtoux fra Morphcat Games “var grafikken og scrollefunktionerne fantastiske sammenlignet med anden hardware på det tidspunkt.”
Da Famicom blev lanceret i 1983, var dens nærmeste konkurrent i Japan faktisk Segas SG-1000. Famicoms grafiske evner var klart overlegne – den havde en palet på over 50 farver sammenlignet med kun 16 på Segas system, sprites kunne have tre farver hver i modsætning til kun én, og skærme kunne scrolles pr. pixel i stedet for pr. tegn, hvilket resulterede i et betydeligt mere jævnt udseende. Nintendos hardware kunne også vise flere sprites i alt og flere sprites pr. scanline. Sega introducerede den grafisk overlegne Mark III-hardware i 1985, hvilket betød, at konkurrencen foregik på mere lige fod, da NES og Master System nåede ud til det internationale publikum.
Redskaberne til at udføre arbejdet
Mens Nintendos 8-bit hardware havde avancerede grafiske muligheder, var de metoder, der blev brugt til at skabe denne grafik, alt andet end avancerede. Ligesom Paul havde kunstneren Kevin Bayliss aldrig set en NES, før han skabte spil til systemet. “På min første dag hos Rare viste Tim [Stamper] mig den grundlæggende ‘pixeleringsproces’ og lærte mig, hvordan man skaber arbejde, der rent faktisk kan bruges i et spil,” fortæller han os.
“Jeg skulle grundlæggende tegne mit kunstværk og placere det under et gitterark på et stort tegnebræt fyldt med fluorescerende strimler. Derefter skulle jeg tegne over min tegning ved at bruge gitteret til at definere pixels med en blyant, og så skulle jeg bruge filtpenne til at udfylde pixels. Derefter skulle arbejdet organiseres og opdeles i kasser (8×8 sprites), og sprite-data og positionsdata skulle alle udregnes i hexadecimal i mit hoved. Det var ret nemt, men til tider lidt besværligt, og man havde ofte ikke lyst til at lave dette arbejde, fordi det slet ikke var kreativt. Man ville bare gerne se sit arbejde i spillet.”
Hvis du undrer dig over, at der ikke var en computer med i den proces, så har du ikke misforstået noget. “Der var ingen andre værktøjer end pen, blyant, papir og en kirurgisk skalpel til at ridse dine fejl op på kalkerpapiret, når du satte en pixel det forkerte sted eller ville skære pixels af en figur, så den kunne klemmes ind i mindre data,” uddyber Kevin. “Der var en simpel sprite-editor, som Mark Betteridge havde skrevet, men den blev ikke rigtig brugt, fordi den var meget begrænset og ikke gav dig mulighed for at se din animation (som de gør i alle de gamle Disney-optagelser ‘bag kulisserne’ – ved at vende dit papir frem og tilbage for at skabe en illusion af animation).”
Der var ingen andre værktøjer end pen, blyant, papir og kirurgisk skalpel til at skrive sine fejl ned med.
Kevin Bayliss
Da NES-udviklingsværktøjerne ikke var standardiserede, blev der brugt en række forskellige værktøjer af forskellige firmaer. Nintendo brugte håndtegnede sprites på et tidspunkt, men skabte til sidst et musestyret pixel-art-værktøj, mens Namco havde et sprite-redigeringsværktøj, der havde den facilitet til forhåndsvisning af animationer, som Kevin beskriver. Han nød dog den lavteknologiske tilgang, som Rare brugte.
“Det var faktisk ret rart at have en begrænset palet. Jeg mener, man kunne på ingen måde have tegnet al sin grafik på papir til en 16-bit konsol, for man ville aldrig have nok penne, og det ville have taget hele dagen at afkode – og man ville have lavet så mange fejl – det ville have været umuligt,” siger han. “Men på grund af farvepalettens enkelhed og den lave opløsning og det lille antal sprites, som vi for det meste beskæftigede os med, var det faktisk ret sjovt at lave grafik på papir, og det føltes meget mere ‘organisk’ end at lave det digitalt på SNES, så det er der vel noget om.”
Uanset hvordan en udvikler skabte kunst til NES, spillede tekniske begrænsninger en rolle for det endelige resultat. “Sprites pr. linje (mere end 64 fyldte pixels i en vandret scanningslinje) var et problem, så man forsøgte ikke at gøre figurerne meget brede,” forklarer Kevin. “For eksempel kan jeg huske, at alle figurerne i de WWF-spil, jeg lavede, enten skulle ‘falde tilbage’ eller ‘ligge på jorden’, og det betød selvfølgelig, at de ville være ret brede i den stilling. Så man prøvede ofte at vinkle dem eller være smart med stillingen, men man kunne aldrig rigtig undgå det. Man kan se, hvordan figurerne ofte blinker frem og tilbage, især i beat-’em-up-spil som det, og det var et problem, som alle firmaer måtte håndtere, så godt de kunne.”
Den karakteristiske flimren er faktisk en smart programmeringsløsning – NES ville simpelthen springe pixels over, hvis der blev vist for mange sprites, så hurtig cykling af sprites til og fra sikrede i det mindste, at de alle ville blive vist i en eller anden form.
(Billedkredit: Nintendo)
Faktisk var NES-udviklerne ofte nødt til at være kreative for at realisere deres visioner – som f.eks. de enorme boss-figurer, Kevin tegnede til Cobra Triangle. “Med Cobra Triangle var vi heldige, fordi spillet foregik i et isometrisk miljø, så al grafikken blev set fra en vinkel, som reducerede den bredde, man normalt ville se i et horisontalt scrollende spil,” siger han.
“Boss-figurerne var alle en samling af store sprites, og vi kunne bruge vandoverfladen til at få ting til at se nedsænkede ud ved at tilføje et par ‘ripple’-sprites omkring dem i bunden. Så for eksempel var den havmonsterfigur (Nessie), jeg skabte, ret høj, og puklerne bag hende bevægede sig rundt uafhængigt af hinanden, og på grund af vinklen var der ikke ret meget flimren i sprites.”
Begrænsningerne blev sværere at håndtere, når man udviklede licensspil, som Rare ofte gjorde. “Til WWF’s wrestlingspil skulle vi sørge for, at figurerne lignede hinanden. Så det var svært at ‘digitalisere’ fotografierne i hånden og gengive alles karakteristika nøjagtigt, når man kun havde omkring 16×16 pixels til et hovedbillede af en figur på select-siden,” siger Kevin. “Jeg kan huske, at jeg fik disse faxer i forfærdelig kvalitet med billeder af wrestlerne, og jeg skulle prøve at genskabe dem ved hjælp af så lav opløsning og tre farver.”
Det førte dog til nogle sjove oplevelser. “Ofte fik jeg faxer tilbage fra Amerika, hvor de sagde, at ‘grafikken trængte til lidt opmærksomhed’, fordi ligheden ikke var helt tæt nok,” fortsætter Kevin. “Så ændrede jeg bare én pixel, og så fik jeg en fax tilbage næste dag, hvor der stod, at billedet var meget bedre. Det fik mig virkelig til at grine, når det skete. Da jeg arbejdede på Beetlejuice-spillet, havde jeg også det modsatte problem, og min titelside lignede åbenbart Michael Keaton for meget, så jeg måtte lave den om, så den lignede Beetlejuice mere – det er lidt svært, når de er den samme person.”
Nuancer imellem
Nogle gange var det muligt at presse systemet ud over dets teoretiske grænser. “Hvis du ser på Super Off Road, vil du bemærke, at der til tider er flere farver på skærmen, end hardwaren kan håndtere som standard,” siger Paul. “Der var fire paletter med hver fire farver, men den første farve i hver palette var den samme baggrundsfarve for alle. Så det samlede antal farver, du kunne vise for baggrundstegn, var 13. Der vises flere i Super Off Road, fordi jeg ændrede paletterne med omhyggeligt timet adgang til VRAM under horisontal blanking. Det fungerede fint,” forklarer Paul, før han retter sig selv. “Det gjorde det i hvert fald på den amerikanske version af NES.
Da spillet var færdigt, fik jeg at vide, at det ville blive udgivet i Japan på Famicom, som var lidt anderledes med hensyn til hardware, og desværre ville min farveskift ikke fungere på den, så jeg tror ikke, det blev udgivet der.”Lyden blev håndteret af den samme Ricoh 2A03-chip, som indeholdt CPU’en. “På NES har du fire lydkanaler at arbejde med. Vi tæller ikke DPCM-kanalen (sample) med, vi bruger den ikke, da den har nogle ulemper,” siger Nicolas, der udvikler moderne NES-spil.
“Uanset hvad er det to firkantbølgegeneratorer, en trekantbølge, som ofte bruges til baslinjer, og en støjkanal, der bruges til perkussive lyde. Så du kan se, at der er begrænsede muligheder for polyfoni og klangfarve, hvilket gør det vanskeligt at skabe et mere atmosfærisk soundtrack, som du ville høre i moderne spil. Det er sandsynligvis en af grundene til, at mange spilsoundtracks dengang gjorde op for det med dynamiske kompositioner og iørefaldende melodier.”
(Billedkredit: Nintendo)
NES-lyd har nogle særligt karakteristiske egenskaber, ikke mindst trekantbølgerne, som er trappetrin i stedet for at være glatte på grund af systemets 4-bit lydbehandling. “På grund af det begrænsede antal kanaler skal du også være opmærksom på, at lydeffekter kan afbryde musikken,” tilføjer Nicolas. “Ideelt set skal lydeffekterne kun afspilles på de kanaler, du bruger til akkompagnement, så de ikke overdøver melodien.”
Lyd er også et af de punkter, der adskiller Famicom fra NES, da Famicom understøtter udvidet lyd via cartridge-porten – noget, som Famicom Disk System og visse specielle cartridge-chips udnytter. Da NES ikke har denne mulighed, har japanske versioner af spil som The Legend Of Zelda og Castlevania III: Dracula’s Curse mærkbart bedre musik end deres internationale modstykker. Faktisk var det de specielle chips, der var en af nøglefaktorerne i NES’ lange levetid. Ud over at understøtte både ROM og RAM på cartridge PCB’er, kunne NES bruge chips, som Nintendo kaldte Memory Management Controllers.
Ud over at give mulighed for bank-switching, der overskred lagerbegrænsningerne i den oprindelige cartridge-specifikation, kunne disse chips give ekstra funktioner til at hjælpe med spiludvikling, og for Famicom endda udvidelseslyd. Det var i sidste ende sådan, at systemet kunne gå fra at være vært for spil som Donkey Kong til meget mere komplekse titler som Kirby’s Adventure i løbet af et årti. Selv med en ROM-kapacitet, der langt oversteg de oprindelige 40 KB, kæmpede udviklerne selvfølgelig ofte for hver eneste byte. “Et almindeligt problem dengang var, at man prøvede at proppe sine spil ned på de små kassetter, vi fik,” siger Paul. “Dette blev kompliceret på NES/Game Boy (begge 8-bit systemer med 64KB hukommelseskort) ved at skulle have bankswitching, hvor regionen kunne være delt op i fire 16KB blokke, og du kunne skifte forskellige ROM-banker ind og ud af dem.
Så man var nødt til omhyggeligt at arrangere, hvilken kode og hvilke data der var hvor, og hvordan man hoppede fra en ROM-bank til en anden i det samme adresserum ved hjælp af standard overlay jump tables i starten af rummet. Vi var også nødt til at udvikle datakomprimeringsrutiner, ofte forskellige til forskellige typer data – tegndata, kortdata, tekstdata, musikdata. Huffman-komprimering blev brugt en hel del, men jeg brugte også tid på at stirre på udskrifter af andre typer data og lede efter mønstre, som jeg kunne bruge til at udvikle komprimeringssoftware til.”
8-bitten
James er ligeledes fuld af lovord om softwaren og siger: “Fællesskabet er fantastisk, og ressourcerne til at bruge tracker-applikationerne er tilgængelige for alle, uanset om du er en erfaren komponist eller bare en fan af chiptunes.” Med disse moderne værktøjer til rådighed har NES-udviklere i dag en tendens til at forsøge sig med meget ambitiøse projekter. Actionspil med fire spillere er en sjældenhed på NES, men Morphcat Games skabte et fremragende et i Micro Mages. Det krævede en meget økonomisk brug af hardwaren.
“NES giver mulighed for, at der maksimalt kan være 64 hardware-sprites på skærmen ad gangen,” begynder Nicolas. “Disse sprites er 8×8 pixels i størrelse (der er en 8×16-tilstand, men den har sine ulemper) og kan sættes sammen til større sprites. “Så for at få en 16×16-sprite i den første tilstand, skal du bruge fire hardware-sprites. Hvis du lader alle fire spillere bruge 16×16 sprites, er det en fjerdedel af alle de tilgængelige hardware sprites, der bruges på spillerne! Der er også en hardwarebegrænsning, der gør, at hvis der er mere end otte sprites på den samme vandrette linje, begynder de at forsvinde,” fortsætter han. “For at afhjælpe dette og stadig give mulighed for mange andre objekter og grafiske effekter på skærmen, bruger spillerfigurerne i Micro Mages en enkelt 8×8 sprite hver.”
8-bit CPU’en viser sig også at være en begrænsende faktor, ifølge Nicolas. “Hvis et spil har en fjende, som kun bevæger sig sidelæns og drejer rundt, når den møder en væg, er det et begrænset antal kontroller, der skal udføres. Menneskelige spillere, på den anden side, er wild cards, de vil interagere med alt omkring dem på måder, som en udvikler ikke helt kan forudsige.
(Billedkreditering: Nintendo)
Jeg elskede at kode NES, det var en helt anden arkitektur end de hjemmecomputere, jeg havde arbejdet på før.
Paul Machacek
Hvis spillerne har mulighed for at skyde, stiger antallet af objekter på skærmen også hurtigt,” fortæller han os. “Det er ikke det store problem i et singleplayer-spil, og man slipper som regel af sted med det i et twoplayer-spil. Men et spil med fire spillere? Av. I Micro Mages har vi brugt meget tid på optimering for at undgå lag. Men i fire-spiller-tilstand er der stadig tilfælde, hvor spillet bliver langsommere, når der sker for meget.”
En fordel, som moderne udviklere har, er muligheden for at vælge og vrage mellem en bred vifte af memory management-løsninger – i dag mere kendt som mappere. “De er bare så interessante at pakke ud og udvikle til,” siger James. På trods af at de har de mest kraftfulde til rådighed, er de ikke altid standardvalget. “Når et spil planlægges til udvikling hos Mega Cat, begynder vi at arbejde baglæns ud fra, hvad der skal til, for at det grundlæggende gameplay bliver sjovt,” forklarer James. “I nogle tilfælde ender vi med at vælge noget kraftfuldt som MMC3-mapperen. I andre tilfælde kan vi holde det simpelt og bruge en diskret mapper, som en NROM.” Det seneste NES-spil Blazing Rangers fra den japanske udvikler Karu_gamo brugte faktisk specifikt den simpleste mapper, NROM’en, til at vække nostalgi for Famicoms tidlige dage. Det er i virkeligheden kernen i udviklernes vedvarende fascination af NES – det er ikke kun et teknisk interessant system, men også et system, der har en stærk nostalgisk tiltrækningskraft.
Selv dem, der først mødte det i en arbejdssammenhæng, som Kevin, føler denne nostalgi. “Jeg nød at arbejde på NES som kunstner, fordi man virkelig kendte systemet til sidst. Uanset om man skabte baggrunde, animerede sprites, titelsider eller front-end-grafik (resultattavle) – man havde et system på plads, som man havde brugt på et tidligere spil, og lejlighedsvis fandt man på noget nyt for at skubbe det lidt længere og presse lidt mere ud af det visuelt. Enkle tider, men sjove!”
Selvom Paul beklager den taljonglering, der ligger i at programmere til 6502, husker han også systemet med glæde. “Jeg elskede at kode NES, det var en helt anden arkitektur end de hjemmecomputere, jeg havde arbejdet på før, der var interessante tricks, man kunne lege med den karaktermappede skærm, som man kunne udnytte til at give dybde – se bare vores Battletoads-spil på NES/Game Boy – og jeg så det hele som en interessant teknisk udfordring at ‘løse’ nye problemer omkring denne alternative hardwarearkitektur.”
Fortidens fremtid
Men trods alt det sjove ved at programmere systemet, peger Paul med rette på resultaterne af dette arbejde som årsagen til NES’ succes. “Man må ikke glemme, at Nintendo havde et utroligt katalog af spil på systemerne, især Super Mario og Zelda. Super Mario Bros 3 var et kæmpe skridt fremad og et absolut højdepunkt på det tidspunkt,” siger han.
Hvis du er en håbefuld retro-spilskaber, er NES måske den ideelle platform for dig. “NES-kode, grafik og lyd er nemme at styre for én person hver i teamet,” siger Nicolas. “Sammenlignet med nu føles programmeringssproget mere obskurt og komplekst end moderne sprog. Alle begrænsningerne tvinger dig til at bruge mere tid på alting,” indrømmer han. “Men det tvinger dig også til at tænke to gange over hver idé. I sidste ende kan man fokusere på dem, der er vigtigst for gameplayet.
Disse begrænsninger kan holde omfanget af dit spil i skak – der er kun så meget, du kan gøre.” Hvis du føler dig tiltrukket af ideen om at tackle den tekniske udfordring, så vis os resultaterne en dag – vi vil altid være interesserede i at se dem.
Denne artikel blev oprindeligt bragt i magasinet Retro Gamer. Hvis du vil have flere fantastiske artikler og interviews, kan du abonnere på Retro Gamer i trykt eller digital udgave her.