Programowanie Nes'a (procesora 6502)

[Berion]

(...) wspomniałeś o klonach to zajebiście mi przypomina płatową organizację obrazu jak w programowaniu VGA (każdy Tiles ma 2 platy, czyli w dwóch różnych bajtach jest po bicie odpowiadającym kolorom?- pomijając paletę?).

4 bo cztery kolory. ;]

Nie idzie znaleźć np źródeł do Prince of Persja?

Do komercyjnych gier nie znajdziesz, nawet abandonware.

Jak spojrzałem na daty ostatnich postów to się trochę przeraziłem, tym bardziej cieszę się, że ktoś zagląda na to forum. Dr88 am nadzieję, że jest ktoś poza Tobą z ludzi zainteresowanych NESAsm zajrzy. Cóż wyjaśni się niedługo.

"W temacie" jest całkiem sporo osób. Prócz Siudyma i Dr88, na pewno Grimm który wszczepia cuda do Dizzy'ego i reszta wypowiadających się w niniejszym temacie (prócz mnie, jam grafik i scenowiec ;]).

Myślę, że gdyby zebrać kilka osób z tego forum możnaby coś sensownego napisać.

Na zeszły zlot z dr88 przygotowaliśmy "na szybkiego" demko na zlot. Ale czy da radę namówić większe grono na "coś większego" to raczej wątpię.

Scena NES to nie scena Atari.

Dobra spadam do magicznej krainy NESAsm-a...

Niechaj ASM 6052 będzie z Tobą. ;]

[Rocket]

Tu masz kody źródłowe do 2 gier: Pocohontas i Boogerman.
http://www.speedyshare.com/files/22676812/Sources.rar

Gdzieś można jeszcze znaleźć kod źródłowy do M.C Kids, tylko nie umiem go teraz znaleźć.

Znalazłem jeszcze kod źródłowy do Metroid'a. Może się przyda:
http://www.romhacking.net/docs/459/

[CodAsm]

Rocket dzięki za źródła, na pewno przydadzą się.

Odnośnie nauki i kursów kończę tłumaczyć na polski tutorial NES, do którego link podalem kilka postów wstecz. Nawet wspominają tam o DMA dla Sprite'ów. Do niedawna nie sądziłem, że w tym 8- bitowym gówienku było DMA...

Znalazłem od groma dokumentacji technicznych NES. W oficjalnej dokumentacji były przypisy do 50 źródeł informacji, za granicą scena i źródła informacji na NES to jednak wymiatają...Czemu u nas tak nie jest skoro każdy na Pegasus'iku kiedyś grał. Nie twierdze, że kazdy gracz musi się interesować, ale przecież nawet ułamek graczy mogłby być ogromna ilością. Cóż pytanie retoryczne.

Dochodzę do wniosku, że na początku póki nie jest się w stanie przewartościować zawartości merytorycznej jakiegośtam znalezionego w necie kursu (jeżeli ma się choć minimalne pojęcie o NESAsm) nie powinno się do takowego zagladać, lepsze są dokumentacje i opisy techniczne.
Później przecież jest już minimum teorii i maksymalna ilość map portów/pamięci no i opisy rejestrów układów NES. Przynajmniej ja tak to sobie wyobrażam.

[dr00id88]

Niewatpliwie, ale zacznij pisac to sie dopiero zaczniesz wkurwiac, jak ci mryga bez powodu:D

A co do tlumaczen, to na pewno bem**rg ci jajca wylize ze szczescia, nie mogl sie nikogo doprosic zeby przetlumaczyc tutki:)

[CodAsm]

Ten tutorial , który obecnie w wersji surowej jest już gotowy (zawartość merytoryczna ok są mapy pamięci, tylko chcę jeszcze ujednolicić i doszlifować). Co do pochodzenia tutoriala, trafiłem na niego całkiem przypadkiem pogrzebłaem na necie i taki sam można znaleźć na stronie głównej PowerPaka toteż, ktoś chyba już o tym źródle informacji wspominał wcześniej w tym wątku.. Idę tłumaczyć oficjalną dokumentację NES, a w wolnym czasie dopracuję wersję ostateczną tekstu, teraz czytam sobie jego polską wersję co o niebo jest wygodniejsze.

Zaczęłem korzystać z FCEUXD SP bardzo wygodny debuger ma. Tylko trochę coś czasem narzeka jak próbuje się odpalić grę, w której nagłówek NES nie jest sformatowany standardowo.

[CodAsm]

Dlatego stwierdzam, że potrzebuję jeszcze czasu i nie chcę puszczać surowej wersji w net. Kilka dni powinno mi wystarczyć (mam sesję, ale powinienem się wyrobić). Notabene, kto by się podjął konsultacji merytorycznej (jeżeli chodzi o język i terminy techniczne)?

[dr00id88]

Pisz tu co potrzebujesz:) btw. co studiujesz?

[CodAsm]

dr88 estem na pierwszym roku infy.

Co do dokumentu z przekładem pozostalo formatowanie tekstu typu czcionki i takie tam dla poprawienia czytelności. Co do terminów angielskich, których nie jestem pewnien, zrobię ich listę i za jakiś czas umieszczę w watku, kto będzie wiedział to napisze najwyżej.

W tym momencie wiem, że nie do końca zrozumiałem pojęcie Scanlinii podczas umieszczania Sprite'ów na ekranie.

Chcialem się jeszcze spytać:
Czy mapy pamieci w ogóle warto tłumaczyć, bo wydaje mi się, że są czytelniejsze po angielsku?

Jako próbkę dam 2 podrozdziały z mojego przekładu kursu NESAASM znajdującego się na stronie PowerPak'a.




Palety

Przed wyświetleniem jakiejkolwiek grafiki na ekranie, musisz ustawić paletę kolorów. Istnieją 2
odrębne 16 bajtowe palety. Jedna jest używana do Tła, druga zaś do Sprite'ów. Bajt w palecie odpowiada jednemu z 52 bazowych kolorów, które NES potrafi wyświetlić. Kolor $0D jest błędnym kolorem i nie powinno się go używać.

Palety w PPU zaczynają się pod adresami $3F00 i $3F10. Do ustawienia adresu palty w PPU używamy portu PPU $2006. Wartość do tego portu musi zostać zapisywana dwuetapowo, raz dla bajta starszego i raz dla młodszego bajta.

   lda $2002 ; odczytaj stan PPU, aby zresetować starszy I młodszy zatrzask
   lda #$3F  
   sta $2006 ; zapisz starszy bajt adresu $3F10
   lda #$10
   sta $2006 ; zapisz młodszy bajt adresu $3F10

Teraz port danych PPU $2007 jest gotowy, aby przyjąć dane. Najpierw pod adresem, który ustawiłeś ($3F00) zostanie dokonany zapis, natępnie PPU inkrementuje adres ($3F01). Po każdorazowym zapisie bajtu do palety adres będzie inkrementowany.
Poniższy przykład ustawia pierwsze 4 kolory w palecie:

   lda #$32  ; jasno sinawy
   sta $2007
   lda #$14  ; różowawy
   sta $2007
   lda #$2A
   sta $2007 ; zielonawy
   lda #$16
   sta $2007 ; czerwonawy

Dalsza część kodu wypełniająca resztę palety, bylaby skonstruowana analogicznie.
Na szczęście istnieje krótszy sposób na napisanie całego tego kodu. Wtedy używa się dyrektywy .db, do umieszczania w pamięci bajtów lub ich grup, które opisywane są etykietą mieszczącą w sobie adres do początku tych danych.

   PaletteData:                     
     .db   $0F, $31, $32, $33, $34, $35, $36, $37, $38, $39, $3A  $38  $3C, $3D, $3E, $0F
     .db   $0F. $1C, $15, $14, $31, $02, $38, $3C, $0F, $1C, $15, $14, $31, $02. $38, $3C

Wtedy, aby skopiować te bajty do palety w PPU, musimy użyć pętli. Rejestr X zostanie użyty jako indeks palety i licznik przebiegów (iteracji) pętli. Chcemy skopiować 32 bajty, zatem pętla zaczyna się z zerową wartością licznika (X) i jest wykonywana dopóki, dopóty X nie osiągnie wartości 32.

   ldx #$00      ; zacznij od x = 0 (Licznik pętli -> x)
      LoadPalettesLoop:
   lda PalleteData, x   ; Załaduj dane spod adresu (PaletteData + wartość w x)
                 ; W pierwszym przebiegu pętli załaduje się PaletteData + 0
                 ; W drugim przebiegu pętli załaduje się    PalleteData + 1
                 ; W trzecim przebiegu pętli załaduje się   PalleteData + 2
            ; itd./etc.
   sta $2007      ; Zapisz do PPU
   inx          ; X = X + 1
   cpx #$20      ; Porównaj X do wartości hex'a $20 = 32d
   bne LoadPalettesLoop   ; Rozgałęzienie do LoadPaletteLoop jeżeli porównanie nie dało
                ; w rezultacie zera, jeżeli porównywana wartość  równa 32 to zakończ pętlę


Duszki (Sprite'y)

Wszystko co będzie się poruszać niezależnie od Tła ma być stworzone jako Sprite. Sprite  jest Tile'em o wymiarach jedynie 8x8 pikseli, który PPU wstawia, w dowolnym miejscu ekranu.
PPU posiada wystarczającą ilość wewnętrznej pamięci na pomieszczenie 64 Sprite'ów.

Sprite'y DMA
Najszybszym i najprostszym sposobem na przeniesienie Twoich Sprite'ów do pamięci Sprite'ów jest użycie DMA (Bezpośredni dostęp do pamięci), Oznacza to po prostu skopiowanie obszaru/bloku pamięci CPU RAM do pamięci PPU RAM. Na kości RAM zwykle do tego celu używany jest obszar adresowy z przedziału $0200-$02FF. By zacząć transfer, do portów PPU nalezy zapisać 2 bajty:

   lda #$00
   sta $2003  ; ustaw młodszy bajt (00) adresu pamięci RAM
   lda #$02
   sta $4014  ; ustaw starszy bajt (02) adresu pamięci RAM. a transfer zostanie rozpoczęty


Podobnie jak z odświeżaniem grafiki, operacja ta musi zostać wykonana na początku powrotu pionowego (VBlank), tak więc kod przytoczony powyżej musi znaleźć w sekcji NMI.


Dane Sprite'ów
Każdy duszek wymaga 4 bajtów danych informujących o położeniu (X,Y), atrybutach oraz nazwie Tile'a,


Współrzędna Y- pionowe położenie Sprite'a na ekranie. $00 jest wierzchołkiem ekranu. Wszystko  znajdujące się za $EF, jest już poza dolną krawędzią ekranu.


Numer Tile'a- jest to numer Tile'a < 0..256> dla grafiki pobieranej z Tablicy Wzorow.

Atrybuty- ten bajt przechowuje informację o kolorze oraz sposobie wyświetlania:

   7 6 5 4 3 2 1 0
   |   |  |      |  |
   |   |  |      + +- Paleta (4 - 7) Sprite'ów
   |   |  |        
   |   |  +------ Pierwszeństwo (0: Przed tlem; 1: Za tłem)
   |  +--------- Odwróć/Pokaż (?) Sprite'a w poziomie
   +----------- Odwróć/Pokaż Sprite'a w pionie

Współrzędna X- Połozenie poziome na ekranie, $00 znajduje się po lewej stronie, natomiast wszystko za $F9 znajduje się poza ekranem

*Jeżeli chcesz zmodyfikować Sprite'a 0, zmieniasz bajty $0300-0303.
*Bajty Sprite'a 1 znajdują się pod adresem $0304-0307
*Informacje o Sprite 2 znajdują się pod adresem $0308-030B, itd.

[dr00id88]

Ktora polibuda:P? Lubelska?

EDIT:

Tiles - liczba mnoga od Tile

[CodAsm]

E tam polibuda zwykła sobie taka uczelnia prywatna dzienna. Całą wiedzę muszę niestety nabywać sam, bo w szkole nie ma za wysokiego poziomu. Pomijając:
-podstawy elektroniki i miernictwa- zadania z kodensatorami, cewkami i tranzystorami
-teorię obwodów i sygnałów- zadania z układów zastepczych rezystorów i nieco teorii
-matma i algebra liniowa- całki i bardzo obszernie macierze
-programowanie i algorytmizacja- nienawidzę, bo wałkuja zadania z matmy w programach i schematy NS (a taki strukturalny zapis algorytmów). Olałem sobie semestr i podrzuciłem kolesiowi mój kod bootloadera ładujacego jadro systemu w systemie plików FAT12.

Ogólnie bardzo się interesuję OSDev, a przecież NESDev to też rodzaj takiego okrojonego systemu operacyjnego, elegancko są wektory przerwań i oczywiscie przerwanie niemaskowalne NMI tylko że w NES pełni raczej rolę odpowiadających im na PC IRQ0 (przerwanie zegarowe na którym opiera się wyswietlanie klatek). NES daje poczucie, że pisze się modyfikację systemu operacyjnego tylko o wiele ciekawszą (jakby nie patrzeć obsługa I/O i przerwań obowiązkowa chociaż to rozwiązanie blizsze BIOS-owi niż potocznie rozumianemu systemowi operacyjnemu).

Składnia NES jest bardzo przejrzysta, tylko mam problem ze zrozumieniem instrukcji stosu. jeżeli ktoś może o tym napisać coś to byłbym wdzięczny.

I ostatnia kwestia, co tyczy się Tiles'ów czasem w trzeba zastosować formę liczby mnogiej wyrazów, zeby słowo nie brzmialo jak ucięte, to był mój celowy zabieg, ale moze w sumie niepotrzebny. Mogę to w sumie poprawić.

[dr00id88]

Jak moze brzmiec jak uciete:)

Jest 1 Tile, a 2 Tilesy:)

[CodAsm]

Ostatnio znalazłem na NESDev bardzo ciekawy dokument pod adresem:
http://nesdev.parodius.com/6502_cn.txt

W końcowej części dokumentu jest bardzo ciekawa rzecz.
Mianowicie, każda instrukcja ze zbioru 6502 jest opisana w postaci listy instrukcji C co pozwala na:
-Całkowite zrozumienie co robi instrukcja i na jakie rejestry, znaczniki oraz inne parametry wpływa
-Napisanie rekompilatora z architektury NES na architekturą 80x86
-Jeżeli pójdziemy dalej można napisać interpreter kodu NES na zwykły komputer, czyli program pełniący jedną z funkcji emulatora

Przykładowo opis dwóch instrukcji (adc i and) 6502 w składni C wygląda tam tak:


/* ADC */
    unsigned int temp = src + AC + (IF_CARRY() ? 1 : 0);
    SET_ZERO(temp & 0xff);    /* This is not valid in decimal mode */
    if (IF_DECIMAL()) {
        if ( ((AC & 0xf) + (src & 0xf) + (IF_CARRY() ? 1 : 0)) > 9) temp += 6;
    SET_SIGN(temp);
    SET_OVERFLOW(!((AC ^ src) & 0x80) && ((AC ^ temp) & 0x80));
    if (temp > 0x99) temp += 96;
    SET_CARRY(temp > 0x99);
    } else {
    SET_SIGN(temp);
    SET_OVERFLOW(!((AC ^ src) & 0x80) && ((AC ^ temp) & 0x80));
    SET_CARRY(temp > 0xff);
    }
    AC = ((BYTE) temp);

/* AND */
    src &= AC;
    SET_SIGN(src);
    SET_ZERO(src);
    AC = src;

--------------------------------------------------------------------------------------------------
Taki projekt kompilatora np. w javie pojawił się na stronie:
http://www.6502asm.com/

[dr00id88]

Nie no 6502_cn.txt ciekawy, z tym ze smierdzi mi tu C :D

ale co do pisania interpretera pod 8086 to uwazam, za niezbyt rozwazny pomysl, zwlaszcza, ze problemem okaza sie Mappery. Mozna to rozwiazac implementujac mappowaniu pamieci, ale to juz robimy z tego emulator;)

[CodAsm]

Oto tymczasowy link do pliku z moim przekładem NESAsm (ze strony NesPowerPack.com w formacie .odt), prosiłbym dawać mi znać na priv jakby coś raziło błędem.

http://www.sendspace.pl/file/b09bc7761db30e8cb295f4f

[dr00id88]

- asembler asembluje, a nie konwertuje;)
- Tile/Tiles juz ci mowilem;)
- praktyka uczy:) Jezeli gra odpali na NesterzeJ, Nestopii, JNesie, to wtedy mozemy spekulowac ze dziala na konsoli. Sam FCEU na duzo niedorobek przymyka oko
- nie The Molester tylko Tile Molester
- dopisz, ze NOAC jest gowniany;)


- w paru miejscach ogonkow ci brakuje, przepusc to przez sprawdzanie pisowni i bedzie ok.


//na razie tyle;)

[CodAsm]

Artykuł powoli poprawiam jak będzie ukończony to wrzucę/odświeżę aktywny link. Poza tym w trakcie pracy nad artykułami o PPU i Mirroring'u na podstawie NESDev oraz kilku innych artykułów. Zastanawiam się czy wklejać takie artykuły w tym wątku czy stworzyć nowy wątek, ponieważ według mnie programowanie procesorów 6502 to dziedzina o dużo szerszym zakresie. Czy ktoś jest zainteresowany w ogóle serią artykułu o Developing-u konsoli NES?

[alzen]

Ja jestem bardzo zainteresowany.

[Grucus]

Składnia NES jest bardzo przejrzysta, tylko mam problem ze zrozumieniem instrukcji stosu. jeżeli ktoś może o tym napisać coś to byłbym wdzięczny.

Jaki problem?

[CodAsm]

O instrukcjach stosowych znalazłem bardzo dobry artykuł, a jego esencją są dwa kawałki kodu, ktore do końca wyjaśniły o co idzie. Ideą tego kodu jest, że wszystkie natychmiastowe dane przechodzą przez akumulator i istnieją rozkazy umożliwiające operacje cząstkowe (np. zanim umieścimy na stosie zawartość rejestru X musimy umieścić ją w akumulatorze i dopiero, gdy znajduje się ona w akumulatorze wrzucamy ją na stos).

;* 1 Kod *

 ldx #$ff   ; Ustaw wskaźnik stosu (rejestr S), na pierwszy element
 txs      ; s = x = #$ff (jest to jedna z czynności wykonywana w kodzie inicjalizacyjnym)

_push_stack:
;Położenie na stosie wartości rejestru A:
 lda #$e0   ; a = #$e0
 pha      ; s = $ff  i a = #$e0

 ldy #$bb   ; y = #$bb
 tya          ; a = y = #$bb
 pha      ; s = $fe  i a= #$bb

 txa          ; a = x; Przed polożeniem wartości x na stosie trzeba ją zapisać do A
 pha      ; Połóż wartość $ff (Pochodzącą z kodu inicjalizującego) na stosie. s=$fd



;* 2 Kod *
_pull_stack:
  pla      ; Zdjęcie wartości $FF oraz skopiowanie jej do rejestru X
  tax      ; S = $fd

  pla      ; Zdejmij ze stosu kolejną wartość (#$bb) i wrzuć ją do rejestru Y.
  tay      ; S = $fe.

  pla      ; Zdejmij $e0 na stos, a później zapisz do A.
      ; S = $ff - Od tego miejsca zaczęliśmy używać obszaru stosu do zapisu danych.

Dochodzą do tego jeszcze instrukcje:

;* -1 Umieszczające na stosie zawartość rejestru statusu procesora (rejestru P)  
        Rozkaz php ( rejestr P -> Stos)

;* -2 Zdejmujące wartość ze stosu do rejestru statusu  procesora (rejestru P)
        Rozkaz plp  ( rejestr  P <- Stos)


To by było na tyle odnośnie stosu. Szkoda, że nie ma on, żadnych sprzętowych zabezpieczeń przed przepełnieniami.

[Koks]

*!* Wydaje mi się że w oryginalnym kodzie ktoś zjadł ostatnią instrukcję procedury _pullstack tzn. ostatniej instrukcji tay (jest dopisana powyżej), bo w komentarzach było napisane, że wartość jest przenoszona do Y.

Wydaje mi się że nie, nie byłoby TAY po drugim zdjęciu ze stosu - wsadzając drugie TAY na końcu nadpisze się poprzednią wartość. Bez tego w X, Y i A jest po jednym elemencie i nic nie ginie.



edit:

pha      ; $1ff = #$e0 oraz s=a=#$e0

s=#$fe
Po każdym wrzuceniu wskaźnik stosu maleje o 1, a nie ustawia się na element wrzucony.