Assembly: Super Nintendo assembly

[TheMaister]

Er det noen andre her som koder eller har kodet litt for Super Nintendo? (65c816). Har begynt så smått å lære meg hardwaren. Får til å vise sprites på skjermen osv. Veldig moro. Prøver å lage Pong, men går sakte framover.

 

Bruker WLA-DX som assembler med bSNES accuracy som test-emulator (slik at koden med 99.99% sannsynlighet kjører på ekte hardware også).

[Jaffe]

Tøft! Nå er vi hvertfall to som driver med retro Nintendoprogrammering her på forumet da. Du får oppdatere oss om fremgangen med spillet.

 

Jeg har ikke prøvd å programmere for SNES, men det ser jo veldig interessant ut. 65c816 er vel i det store og det hele ganske lik 6502 når det gjelder instruksjoner og registre (utenom flere addressing modes og større registre da). Hvordan er det med grafikk for SNES? Jeg antar den har en noe mer medgjørlig grafikkprosessor . (Med NES må man jo f.eks. bestemme paletten til tiles i bakgrunnen ved å pakke to biter for hver tile i et 2x2-rutenett inn i en byte og så plassere denne i et såkalt pattern table. Ganske bakvendt og tar mange klokkesykluser.)

[TheMaister]

Yup, 65c816 er veldig likt 6502 på mange måter. Den har faktisk en emuleringsmodus som da funker mer eller mindre helt likt som 6502.

 

Noe av det rareste med 65c816 er at man kan "at will" bytte mellom 8- og 16-bit A, X og Y registre. Litt merkelig, men begynner å bli vandt med det. Pleier å ha A på 8-bit og X/Y på 16-bit. Den har også noen morsomme addressing modes, ja

 

SNES har tre forskjellige RAM som har med grafikk å gjøre.

OAM er object attribute memory på 544 bytes (512 + 32) or har med sprites å gjøre. SNES har visst 128 hardware sprites og i OAM settes attributes som f.eks hvilken sprite som skal brukes, posisjon på skjerm, palett som brukes, osv. Hver entry er på 4 bytes. I den høye delen av OAM (32 bytes) settes noen ekstra ting som f.eks å flytte spriten ut av skjerm osv.

 

CGRAM er hvor palettene lagres. Egentlig ganske greit. Farger er 16-bit XBRG1555. Den er på 512 bytes, så man kan ha maks 256 farger.

 

VRAM er ... VRAM. Her ligger sprites, tiles og tile maps.

Tiles/sprites er lagret i et merkelig bitplate format.

 

SNES har også DMA for en kjapp memcpy() til VRAM, OAM, CGRAM osv Har ikke sett noe særlig på HDMA, men kan visstnok lage noen veldig kule effekter med den.

 

 

Har så smått fått til en (grell) bakgrunn til pongen

GitHub: https://github.com/Themaister/SFC-Pong

 

Så var det å få noe til å skje ...

Endret 2. april 2011 av TheMaister

[TheMaister]

Fikk til litt mer Collition detection osv. Er sånn ... halvveis spillbart.

 

Source:

https://github.com/Themaister/SFC-Pong

git://github.com/Themaister/SFC-Pong.git

 

ROM: http://maister.homelinux.org/downloads/pong.sfc

[Jaffe]

Det begynner jo allerede å se lovende ut dette. Koden ser veldig pen ut også.

[TheMaister]

Hadde en del problemer med å implementere denne konstruksjonen, men funket visst ...

 

if (BallPosX < 0x10 || BallPosX >= 0xF0) { do_shit(); } // 

 

Den ble seende slik ut:

lda BallPosX
  cmp #$10
  bcs +
  lda #$01
  inc Player2Score
  bra ++
+ lda #$00
++ pha

  lda BallPosX
  cmp #$F0
  bcs +
  lda #$00
  bra ++
+ lda #$01
  inc Player1Score
++ clc
  adc 1, s
  cmp #$01
  bcs +
  pla
  bra _check_score_end
+ pla

 

Er det en mer "sane" måte å implementere dette på?

[Jaffe]

Om det går an å gjøre det så mye mer "sane" vet jeg ikke

 

Men det er vel ikke akkurat den konstruksjonen den koden der implementerer? Hvorfor pushes A på stacken egentlig?

[TheMaister]

Det jeg prøver på er å evaluere

BallPosX < 0x10

lagre 1 (true) eller 0. Siden jeg må evaluere det andre også pusher jeg resultatet på stack.

 

Så evauleres

BallPosX >= 0xF0

Samme skjer her, hvis da summen av A og 1,s (lagret verdi) er minst 1 evalueres uttrykket til true.

 

Er vel kanskje mulig å gjøre det litt mer clean på denne måten (i C-pseudokode):

if (BallPosX < 0x10) goto is_true;
if (BallPosX >= 0xF0) goto is_true;
return;
is_true:
  do_stuff();
return;

 

 

EDIT: Hm, dette bør funke:

  lda BallPosX
  cmp #$10
  bcs +
  inc Player2Score
  bra _check_score_is_true

+  lda BallPosX
  cmp #$F0
  bcc _check_score_end
  inc Player1Score

Endret 3. april 2011 av TheMaister

[Jaffe]

Det blir nok litt renere ja. Det er i alle fall slik det er vanlig å gjøre det.

[TheMaister]

Tok en titt igjen på NES-dokumentene dine. Forrige gang jeg prøvde ble det alt for vanskelig, men NESen virker passelig lik ja. Samme måte å skrive ting til VRAM osv. (Skrive først til addresses register, også spamme data til ett register.)

[Jaffe]

Ja, det virker som det er mye av den samme måten å gjøre ting på. Det er egentlig ganske tungvint (men samtidig forståelig) at CPU og PPU ikke deler samme addresse- og databuss. Heldigvis har også NES-PPU-en en DMA-kontroller som kan kopiere 256 bytes fra en page i RAM og over til OAM. Bare sånn til advarsel så må du ikke ta alt i de (gamle) dokumentene for god fisk... Det begynner å bli lenge siden jeg skreiv dem, og det er en del unøyaktigheter.

[TheMaister]

Hehe. Har begynt å snuse på SPC-700, som er lydchippen i SNES. Er en fullblods coprosessor med sitt eget assemblyspråk (passelig likt 6502/65c816 dog) og kjører asynkront (hvis jeg har forstått det rett) med CPUen.

 

Kommunikasjon skjer over 4 8-bit busser og protokollen består i stor grad av busywaiting på verdier for handshaking ... Dette blir vanskelig ...

[TheMaister]

Jadda! SPC-en virker. Det ble svært mye debugging, så jeg må takke bSNES-debuggeren.

 

Ga opp å lage en .spc loader. Var noen svært merkelige stall-bugs jeg ikke klarte fikse, men gikk heller for å skrive et SPC program fra scratch.

 

SPC-en starter opp med en hardkoda ROM lagret i den som implementerer en veldig primitiv protokoll for å kunne overføre sitt eget program. Når man er ferdig kan man bestemme hvor SPCen skal hoppe til. Etter det har man full kontroll over hva som skjer, og man kan da implementere sine egne protokoller for å gjøre ting man trenger. I mitt tilfelle blir SPC programmet seende noe slik ut i pseudokode:

 

0. Sett intern counter til 0.
1. Skriv intern counter til I/O #0.
2. Sett opp DSPen med riktige verdier for sample, envelope, filter, osv. (En liten lydeffekt når kula treffer vegg eller pillar).
3. Vent på at CPU skriver intern counter tilbake (handshake).
4. Les magisk byte som CPUen sender på I/O #1.
5. Øk intern magisk byte og skriv denne til I/O #0.
6. Echo magisk byte som CPUen sendte til I/O #1 igjen.
7. Spill lydsample.
8. Goto 3.

[Jaffe]

Det så jo ganske krøkkete ut ja, men regner med det er gankse ok når man har fått satt opp egne protokoller etc.? Var det mye styr med å få til ekkoeffekten (jeg regner med det er det det er? )

 

Hvordan er WLA-DX forresten? Jeg har nettopp byttet fra NESASM til CA65 (det har etter hvert vist seg at NESASM har sine ... mangler), men WLA-DX kan jo også være et mulig alternativ.

 

(Har forresten merket at ballen av og til går gjennom paddelen, men det er vel sikkert bare en liten glitch.)

[TheMaister]

SPC-700 på kommunikasjonssiden er ganske krøkkete greier ja. Akkurat DSP-biten ser ut til å være ganske rett fram, så echo-effekt var ikke spesielt vanskelig. Problemet er nok å klare å bruke den til å lage faktisk bra musikk ... Kjenner igjen mye fra konvensjonelle synther (ADSR), osv, så er ikke helt ukjent terreng. Den har også en 64kHz timer som sikkert kan brukes til å kontrollere tempo, osv.

SPC-700 koden: https://github.com/Themaister/SFC-Pong/blob/master/pong_spc.s

 

Bruker en litt stor echo buffer med litt feedback for "tennis"-lyden.

 

WLA-DX er helt greit for min del. Den har en 65c815 assembler og en spc700-assembler som ser ut til å funke. Veit WLA-DX har sine mangler og quirks, men har ikke støtt på noe snusk enda i hvertfall. Har sett to større SNES homebrew og de bruker begge WLA, så regner med det er ålreit for større prosjekter også.

 

Ja, collition detection på paddene er veldig dårlig atm Er spesielt på kantene det ikke er helt optimalt.

Endret 6. april 2011 av TheMaister

[TheMaister]

Fått litt mer fart på grafikksida i hvertfall. Skrev et lite verktøy for å oversette et helt vanlig bilde til palett, tiles og tilemap direkte. Veldig trivielle algoritmer, så bruker ikke per-tile paletter, osv, og er statisk 16 farger og 8x8 tiles atm, men ser ut til å funke ganske bra Nå ser pong slik ut:

 

[Jaffe]

Tøft. Så bedre ut nå ja! Merket forresten at den ene paddelen beveger seg sidelengs når den andre beveges opp og ned, er dette meningen?

[TheMaister]

Hehe. Ja, har en dummy-implementasjon for CPU-spilleren atm (2-player kan hoppe inn med start). Ga opp å gjøre det bra, så gjorde detta...

 

; Calculate AI movement for player 2. Not very good algorithm ... 
CalculateAIMovement:
  pha

  lda Joypad1Up
  sta Joypad2Left
  lda Joypad1Right
  sta Joypad2Down
  lda Joypad1Down
  sta Joypad2Right
  lda Joypad1Left
  sta Joypad2Up

  pla
  rts

 

...