Guide: Nintendo NES-programmering

[frankhaugen]

...

 

KJEMPEBRA!!!

 

Trenger utfylling og en go del mer for å gjøre den komplett, men dette er faktisk bra nok til at du kan forsøke å få den trykket! Hør med Universitetsforlaget

 

-frank

[Jaffe]

Hehe, takk Men jeg tviler nok på at noe som helst forlag er interessert i å gi ut dette. Dessuten ønsker jeg vel egentlig at flest mulig skal få tilgang til dette gratis.

[89erik]

Enig, guiden er skikkelig godt skrevet

Er veldig nysgjerrig på hvorfor du kan så mye om dette, hva er bakgrunnen din Jaffe?

[Jaffe]

Takk

 

Bakgrunnen min er hobbyprogrammering de siste ti årene. Begynte med NES-programmering for rundt sju år siden, og har drevet med det litt av og på frem til i dag. I løpet av den tiden har jeg såklart fått med meg en god del ting. Har lært spesielt mye av å lage (det dårlige) spillet NF-ball (kilde) i 2006 og NES-porten av Chip's Challenge som det linkes til i signaturen min (holder på med den enda).

 

Jeg begynte å skrive den første guiden dels for å få et bedre overblikk over NES-en selv, men mest fordi jeg alltid har vært glad i å forklare til andre om ting jeg syns er interessante. Jeg går på Lektorutdanning i realfag i dag, og det er av den samme grunnen.

Endret 24. juli 2012 av Jaffe

[89erik]

Ok! Tenkte kanskje du studerte data Er det LUR ved NTNU?

[Jaffe]

Ja, går LUR på NTNU. Studerer du noe der du også?

[89erik]

Ah, kult Ja, jeg går på informatikk. Vi driver stort sett med høynivå-programmering i java, men jeg hadde nylig et fag som fokuserte på assembly og C. Fant ut at jeg liker det mye bedre

[Jaffe]

Ah, NTNU du også altså. Hvilket fag var det du tok?

 

Jeg liker forsåvidt både høy- og lavnivåprogrammering. Det ene er et greit avbrekk fra det andre I fjor laget jeg en mapeditor til Chip's Challenge-porten som jeg holder på med, og da brukte jeg Common Lisp, rett og slett fordi jeg var så lei av å programmere lavnivå (og ville friske opp i CL).

 

Jeg har forresten ordnet litt på noen ting i guiden (mer spesifikt om statusflaggene, negative tall (toerkomplement) og adresseringsmåtene). I tillegg har jeg lagt inn hyperlinker i dokumentet, slik at man f.eks. kan trykke på det avsnittet man vil lese i innholdsfortegnelsen. Har også laget en liten ordliste bakerst.

[89erik]

TDT4258 Mikrokontroller Systemdesign (byttet nylig navn til Energieffektive Datasystemer). Det handler stort sett om å programmere en STK1000 mikrokontroller først med assembly, deretter C uten OS og til slutt C på Linux med egenlagde drivere.

 

At det ene er avbrekk fra det andre stemmer nok veldig for meg og. Jeg må innrømme at jeg koste meg voldsomt med det forrige prosjektet mitt som var ganske rent objektorientert. Men nå for tiden er jeg helt frelst av de små detaljene, atomiske instruksjonene og ikke minst den store kontrollen over hardware man får i lavnivå.

 

 

Nå begynner NES-spillet mitt forresten å nærme seg ferdig, så hvis du eller eventuelle andre som følger tråden er interessert i å se: kompilert fil, kildekode (trykk A på én av kontrollerne når noen scorer).

[Jaffe]

Stilig! Liker hvordan bakgrunnen scroller, og fargeeffektene når noen scorer. Må si du har lært mye veldig fort! Koden ser veldig bra ut også.

 

TDT4258 så veldig interessant ut. Kanskje jeg må ta dette til våren.

[89erik]

Takk!

TDT4258 kan jeg absolutt anbefale.

[Jaffe]

Nå har jeg laget et nytt eksempel. Kan være det bør forklares enda mer, men jeg tror det bør være forståelig hvordan det fungerer.

[89erik]

Kult! Så også at du la til litt om lydprosessoren, det ser spennende ut! I det faget jeg snakket om produserte vi kunstige lydbølger helt på egen hånd, med et klokkesignal som kalte på en funksjon med statiske variabler som holdt styr på hvor i lydbølgen man var, og med det bestemte amplituden for hvert klokkesignal. Det var ganske gøy Gleder meg til å få NESen til å lage litt lyd.

 

Jeg flytta forresten alle variablene mine over i et zero page segment, og kompilatoren klager over at jeg ikke bruker 'zeropage adressing' når jeg henviser til dem. Når jeg adresserer med < for den lave delen av adressen, får jeg warning om 'suspicious address expression'. Hvordan ser egentlig zero page adressing ut?

[Jaffe]

Syntaksen til zero page adressering er lik syntaksen til absolutt adressering. Assembleren skal optimalisere dette automatisk. Hvis den ser en henvisning til noe som har en adresse mellom 0 og $FF, velger den zero page-adressering.

 

Hva mener du egentlig med at du har flyttet til zero page? I koden som ligger på GitHub ligger variablene allerede i zero page, siden du definerer dem i starten av RAM-segmentet.

 

Angående lyd så er nok ikke NES-en like fleksibel som det dere gjorde i det faget. Square-kanalene og triangle-kanalen er låste til å lage bølger av den ene typen. Den kanalen som kanskje kommer nærmest er delta-kanalen. Denne er i utgangspunktet ment å brukes med såkalt deltamodulasjon (den leser en strøm med bits og tolker 1 som "gå opp" og 0 som "gå ned". 11110000 vil f.eks. altså produsere en bølge som går fire steg opp og så fire steg ned igjen), men den kan også gis en amplitude direkte. Problemet er at det må gjøres svært ofte, og CPU-en er nødt til å bruke alle ressurser på det, så det er egentlig ikke så aktuelt.

[89erik]

Jo, de var vel det men tenkte det var mer korrekt å gjøre det på denne måten. Forskjellen er at segmentet nå er av type zp (som jeg egentlig ikke vet helt hva som er fordelen med).

 

 

SEGMENTS {
...
ZEROPAGE: load = RAM_SEG, type = zp;
...
}

 

Og koden er eksempelvis slik:

 

.segment "ZEROPAGE"
variabel: .byte 0

.segment "CODE"
LDA #0
STA variabel

Endret 1. august 2012 av 89erik

[Jaffe]

Hmm, det var rart. Hvis du ser på eksemplene fra 2 til 5 så gjør alle disse det samme som det du gjør her. Jeg får ingen feilmeldinger når jeg assembler og linker disse. Hvordan er koden din sammenlignet med disse eksemplene?

 

Nå ser det visst ut som jeg har misforstått noe selv. Det er faktisk nødvendig å definere alle labelene i et zero page-segment for at instruksjonene skal få zero page-adressering. Det er visst kun når adressen er et tall at den sjekker om den er mellom 0 og $FF. Så da var det en god idé å lage et zero page-segment likevel (og det er altså det som er grunnen til at man har 'zp'-typen). Den eneste grunnen til at jeg gjorde det i eksemplene fra 2 til 5 var at jeg uansett måtte dele opp RAM-en og lage OAM-segmentet. Jeg tenkte egentlig ikke på adresseringen.

[Jaffe]

Har begynt å skrive på kap. 6 (om APU-en) nå. Så langt har jeg skrevet om square-kanalene. Håper det er forståelig (bekymrer meg litt for at det er for mye tekniske ting der som egentlig ikke er viktige for å få til å lage lyd).

[89erik]

Å bytte fra "ZEROPAGE" til "ZERO_PAGE" løste visst problemet mitt... Det er fortsatt type = zp. Dette var merkelig...

 

Jeg starter på kap 6 i kveld

[Jaffe]

Det var veldig rart, ja. Jeg gjør jo akkurat det samme i eksempel 2 - 5, og hos meg går det fint å assemble og linke disse.

[89erik]

Som du sikkert skjønte gav jeg opp det forrige prosjektet, semesteret begynte igjen Men nå har jeg endelig begynt på et nytt prosjekt. Prøver å implementere Breakout, koden ligger her hvis noen skulle være interessert.

Kanskje interessant for andre utviklerere er noen generelle prosedyrer som jeg merker jeg trenger med jevne mellomrom som jeg har samlet i en fil her. Det er stort sett operasjoner på "signed" tall (tall som kan være negative), som f.eks. absoluttverdi, aritmetisk right shift (deler på 2 som også fungerer med negative tall), og sammenligning av signed tall.

Endret 16. mars 2014 av 89erik