Przypominam sobie, że w Koszycach jest knajpa, w której sprzedają świeżo uwarzone piwo. Knajpa nazywa się Golem i jest zaraz przy rynku. Adres Dominikańskie namesti 15.

Jakibądź edytor do sampli. Jeśli nie zredukujesz do 4-bit unsigned, to przynajmniej do 8-bit, a dalszą konwersję robisz własnym programem.

Innymi słowy przyczyniłem się walnie do twego rozwoju - nie ma sprawy, nie oczekuję wiele w zamian, wystarczy mi jakieś osiem piw na najbliższym party :P

No dobrze, podsumujmy. Twoja propozycja:

1) zakłada użycie nielegalnego skoku do systemu
2) zajmuje sporo miejsca i jeszcze więcej cykli maszynowych
3) zakłada użycie danych, które są już zdjęte ze stosu
4) i z tego względu może działać tylko przy wyłączonych przerwaniach.

Sam przyznasz, że do podręcznika programowania to się raczej nie nadaje, chyba że jako antyprzykład :P

Co do tego stosu, można to spróbować zrobić inaczej. Mianowicie zapisujesz w spokojnym miejscu (np. na szóstej stronie) takie coś:

lea  pla
     clc
     adc #$01
     sta ret
     pla
     adc #$00
     sta ret+1
     jmp (ret)

Po wywołaniu JSR LEA w komórkach RET i RET+1 masz adres pierwszego rozkazu po JSR. Program nadal jednek nie jest w stu procentach niezależny od umieszczenia w pamięci, wydaje mi się, że takowy mozna stworzyć dopiero na 65C816 (mam tak np. rozpisany podprogram PRINTF, skompilowany kod można umieścić gdziekolwiek, np. w stringu BASIC-a, i zawsze działa).

EDIT: oczywiście popierdzieliła mi się kolejność bajtów na stosie. Teraz jest dobrze.

Ale za to nie będzie ci działać, jeśli pod $C0CE nie ma tego, co zakładasz, że jest (a np. w Atari 400 i 800 nie ma tam nic). Ciekaw jestem, czy w QMEG-OS jest, bo w moim ROM-ie dla 65c816 nie ma z całą pewnością.

Zastanawiam się w ogóle, jaki sens ma ta kombinacja (php / jsr $c0ce). Zakładając nawet, że pod tym adresem jest rozkaz RTI. O ile mi wiadomo, JSR odkłada na stos adres powrotny pomniejszony o jeden, a przerwanie nie. Wobec tego JSR $C0CE odłoży na stos adres ostatniego bajtu argumentu rozkazu JSR, a RTI do tegoż ostatniego bajtu powróci (bo RTS zwiększa adres o 1, ale RTI nie). Po wykonaniu JSR (na standardowym ROM-ie) zostanie wykonany nie rozkaz TSX, ale CPY #$BA (gdzie $C0 to opcod CPY #, a $BA to opcod rozkazu TSX). Zastanawiam się, co ci to daje.

Domniemywam, że owo JSR ma wstawiać na stos adres bezwzględny kodu znajdującego się za JSR. Nawet jednak, gdyby tak było (a nie jest, patrz wyżej), to RTI ten adres ze stosu zdejmuje zwiększając przy tym wartość wskaźnika stosu. A pierwsze przerwanie - które może wystąpić zawsze, a więc natychmiast po wykonaniu się RTI również - ten adres skutecznie zamazuje. Toteż późniejszymi rozkazami (tsx, lda nnn,x itd.) zdejmujesz ze stosu wyłącznie śmieci, a program idzie w maliny.

Ja tam nigdy nie jestem od tego ;)

W Warszawie :) Uksword to inaczej UKSW, czyli Uniwersytet im. Kardynała Stefana Wyszyńskiego, dawniej ATK.

Banalnie prosto.

Może, w zasadzie, ale ma to dwa mankamenty:

a) wydłuża tablicę fixupów (na oko dwukrotnie)

b) wymaga, żeby tąż tablicę fixupów generował kompilator

Punkt b) to problem bez wyjścia, kiedy kompilator, którego używasz, nie generuje kodu relokowalnego.

A co, jeśli program ma np. 48k źródłówki i ponad 512 etykiet? :P

Nie ma tu sprzeczności. Pismo mówi bowiem: można swobodnie i bez trudu korzystać z adresów bezpośrednich (natychmiastowych), gdy wyrówna się adres ładowania do granicy strony. Wtedy bowiem fixupowaniu podlegają tylko starsze bajty wewnętrznych adresów programu - a istotą rzeczy jest nie, że starsze czy nie starsze, ale że w każdym razie pojedyczne bajty programu podlegają fixupowaniu, i tym samym nie ma potrzeby dodawania z przeniesieniem całego adresu ładowania do wszystkich wewnętrznych adresów programu; a tylko starszy bajt adresu ładowania do wszystkich starszych bajtów jest dodawany i to bez przeniesienia.

Nie jest więc istotne, czy adres jest zapisany na dwóch kolejnych bajtach (lda adres / sta vec), czy na dwóch, ale nie kolejnych (lda #<adres / sta vec). Poniał? :)

Co więcej, jeśli założysz, że jakaś tablica ma ci się zaczynać od granicy stron, to taka relokacja sprawia, że ta tablica zawsze się od granicy stron będzie zaczynać.

Z informacji o fixupach dołączonej do relokowanego pliku binarnego.

A starszy traktuje się tak samo, jak wszystkie inne starsze bajty wewnętrznych adresów tego pliku.

Istnieje jednak prostsza, krótsza i o niebo bardziej elegancka metoda (zastosowana juz przez ICD w kodzie SpartaDOS X, na wypadek, gdyby ktoś myślał, że to wynalazek L.K. Avalonu, podobnie jak śmigłowiec, samolot itp.):

     lda dadr
     sta vec
     lda dadr+1
     sta vec+1
     ...
dadr .word dane

Wystarczy wyrównać adres ładowania do granicy strony i już można (bo zmieniają się tylko starsze bajty takich adresów).