Ja wpadlem na cos takiego (mam nadzieje, ze sie nie wyglupilem, bo nie uruchamialem):

.ab
php
rep #$20
lda #$00
dec
plp
lsr

Powinna zwracac to samo co Twoja (8 bajtow, 14 albo 15 cykli ;))

Chodzi o taki mily trick, zeby wykorzystac fakt, ze 6502 bardzo lubi liczbe 256  ;). Jezeli wiec podzielimy sobie kat pelny nie na 360 jednostek, a na 256, to obliczenia trygonometryczne (uzywajac tablic sin cos i pochodnych) baaardzo nam sie uproszcza.

pozdrawiam

Ja mam nadzieje, ze Vasco jedzie i zabiore sie z nim jak rok temu... bo jak nie to moze byc kiepsko. Ale na pewno pojade

wydaje mi sie ze na podstawie tych zrodel powstal wlasnie ultraXE...

W atari za pomoca beja tez ciezko uzyskac 256 kolorow. A co do konstruktorki, to podoba mi sie jej rejestracja :) Ja zawsze szukalem polskiego radiowozu z taka rejestracja, ale nie znalazlem (inne MOSy widzialem, ale nie 6502). Ciekawe, czy taki istnieje...   :?:

Greensleeves to tradycyjny angielski utwor. Wielu artystow siegalo po niego. M.in. Loreena McKennitt czy Leonard Cohen. Co do nutek, to "google Twoim przyjacielem" i znalazlem cos takiego  ;) .

hehe... kiedys do -=New Generation=- liczyl tez solo ale szybko mu sie znudzilo :P
Od paru ladnych dni nic nie policzylem, bo w akademiku net mi padl (zabic admina), ale bede jeszcze walczyl :)

Pisanie zupelnie nowego asemblera uwazam za zbyt kosztowne... jak juz, to lepiej byloby porozmawiac z BOBerem, aby dodac te ficzery do jego wciaz przeciez rozwijanego asemblera.

Ja jednak sklaniam sie do innego rozwiazania i (nie ukrywam) wiaze sie ono z moja "fascynacja" ca65. Od kilku miesiecy pracuje (mam nadzieje, ze mi sie uda) nad nastepca systemu, ktory wykorzystalismy w LFove, a bedzie to taki "demo-linker". Podstawowa idea, to wykorzystanie naturalnego dla tego asemblera podzialu na segmenty oraz odpowiednie deklaracje, czy segment ma byc w pamieci podstawowej, czy moze w banku i linker majac wszystkie informacje o calym projekcie sam rozlokuje wszystkie segmenty w odpowiednich adresach i bankach (zeby nic nam nie kolidowalo). Wystarczy tylko dodac ustawiana przez linker zmienna np. nazwa_segmentuBankNumber, ktora dla kazdego segmentu, ktory jest w banku zostanie ustalona na wartosc z tablicy bankow i wszystko pieknia nam smiga i nie musiby dbac o zadne adresy... kolizje... bo po co, skoro mozna to rozwiazac automatycznie, a przy dobrym algorytmie automat zrobi to lepiej niz czlowiek.

A co do pomyslu Pirxa o kompilowaniu utilow unixowych, to na zwyklym 6502 projekt bylby o tyle  trudny, o ile mamy wielkie ograniczenia z uzywaniem dynamicznej pamieci. Nawet najzmyslniejszy linker pozwolilby nam zaalokowac max 16kB, a jesli na nieszczescie procedura probujaca sie odwolac do tego obszaru znalazla sie w innym banku, albo gdybysmy na przemian chcieli odwolywac sie do danych w roznych bankach, to mamy klops. MOZNA specjalnie pisac, zeby wszystko dzialalo OK, ale nie powinnismy oczekiwac, ze dowolny program bedzie dziala przy takich ograniczeniach. Co innego na 65c816 z odpowiednia iloscia dodatkowej pamieci... w takiej sytuacji to nic nowego nie jest potrzebne. Standardowy (acz odpowiednio nastrojony) linker do cc65 poradzi sobie znakomicie.

O wlasnie. Nawiazujac do poprzedniej wypowiedzi truba juz chyba potrafie nazwac o co mi chodzilo i sprecyzowac moje "watpliwosci", jako bardziej "ideowe". Ostrzegam, ze bede fantazjowal ;) Relokowalny format binarny, to super pomysl, tylko trzeba zadac sobie pytanie o potrzebe takiego formatu. Normalnie dla standardowego ATARI OS wydaje mi sie on malo przydatny, gdyz pomijajac przypadki instalowania roznych rezydentnych nakladek w pamieci atari na raz przebywa i tak tylko jeden program i nie musi on dzielic zasobow z zadnym innym, przez co nie ma konfliktow adresowych. Relokacja wydaje sie jednak niezbedna dopiero przy wielozadaniowosci, lub przynajmniej przy powaznym wsparciu dla rezydowania w pamieci wielu programow przez system operacyjny. Prawdziwy multitasking na atari wydaje sie szalenie trudny do uzyskania, ale w przypadku 65c816 i duzej ilosci pamieci ta druga opcja jest jak najbardziej mozliwa. Dosc mile sa wizje wspierania przez atarowski OS odpowiednika windowsowego Alt+TAB, aby moc uruchomic sobie kilka narzedzi rownoczesnie i przelaczac sie pomiedzy nimi. I to wg. mnie ma sens. Tylko do tego potrzebny jest SILNY system operacyjny. Jezeli juz bysmy taki mieli, to dlaczego plik relokowalny musialby byc taki ubogi? Dlaczego by nie wprowadzic np. koncepcji zmiennych systemowych, czyli symboli, ktore normalnie w asemblowanym kodzie bylyby deklarowane jako zewnetrzne i podczas ladowania system (loader) przypisywalby im konkretne wartosci jak np. rozmiar dodatkowej pamieci, rodzaj procesora, czy chociazby numer banku (wartosc PORTB) przydzielona programowi gdy potrzebuje on dodatkowej pamieci. Wiem, ze troche zagalopowalem sie teraz z fantazjowaniem, ale wg mnie relokowanie ma najwiekszy sens przy obecnosci rozbudowanego srodowiska systemowego, ktore w polaczeniu z duzym potencjalem formatu pliku dawaloby wielkie mozliwosci.
Nie chce byc oczywiscie jednostronny i zdaje sobie sprawe, juz przy standardowym OSie jezeli nie pisze sie dema, to fajnie byloby zwrocic uwage na wartosc MEMLO i dopiero od niej ustawic program. Wlasnie ze wzgledu na rezydenty. Do takich celow proponowany przec Draco format w zupelnosci wystarcza i nawet nie musimy zawracac sobie glowy jakimis segmentami DATA czy BSS, bo ich przydatnosc wydaje sie wtedy watpliwa.

Naszly mnie takie luzne przemyslenia. Jak dziala program mkrel.com? Czy na wejsciu przyjmuje on standardowy atarowski plik ladowalny (naglowek $ffff) ? Rozumiem, ze jego zadaniem jest odjecie od kazdego absolutnego odwolania wewnatrz programu adresu jego poczatku oraz skojarzenia z tym adresem fixupa. Ale nie wyobrazam sobie jak znalezc wszystkie takie odwolania oraz jak nie potraktowac tym odwolania, ktore nie powinno byc zrelokowane lub wrecz bylby to fragment danych, ktory przypadkiem wyglada jak odwolanie. Istnieja rzeczywiscie takie problemy, czy moze mysle zbyt pesymistycznie? Moge pisac glupoty, ale wydaje mi sie, ze tak naprawde nie mamy na atari porzadnego supportu dla plikow relokowalnych, a programy urelokowalniajace absolutny kod sa tylko jakas zastepcza metoda radzenia sobie z problemem w ograniczonym zakresie. Widze tu pewien konkretny problem techniczny zwiazany z efektywnym generowanie relokowalnego kodu i nie widze uniwersalnego rozwiazania, gdyz jedyny asembler jaki znam, ktory generuje prawdziwy kod relokowalny to wspomniany przeze mnie wyzej ca65, ale jest to cross-assembler, a na prawdziwym atari niczego takiego nie znam. Koknretnie pewien impas widze w tym, ze proponowany format moze byc zbyt obszerny przy generowaniu relokowalnego kodu z programow pierwotnie absolutnych (bo piszac w ten sposob pewne trudnosci moze sprawic pelne wykorzystanie dobrodziejstw wielu segmentow), a rownoczesnie zbyt skromny przy pisaniu programow w ca65, ktory daje o wiele wieksze mozliwosci.
Przepraszam, za zasmiecenie topiku postem, z ktorego nic nie wynika, ale czulem potrzebe podzielenia sie moimi "watpliwosciami" ;)

Wlasnie sprawdzilem. Wstawienie Twojej procedurki do mojego monitorka bylo calkowicie bezbolesne, gdyz obie zwracaja to samo (tylko mi sie glupio zrobilo, ze moja byla z dwa razy dluzsza  ;) ). Procka udowodnila, ze dziala zwracajac dokladnie takie same wartosci co moja, a wiec 16 bankow przy obecnym 1 MB i 1 bank przy wylaczonej pamieci dodatkowej (Pasiu zaopatrzyl mnie w zworke, ktora moge tego dokonac  :D )

Tak. Mam 1 MB w bankach (na SIMie by Pasiu). Megabajt liniowej mam oczywiscie osobno  ;)

PS. Jak Ci sie chce, mozemy zastanowic sie, co jest nie tak. Moja procka na wykrywanie liniowej pamieci jest taka (kod dla cross-assemblerka ACME):

;Obliczanie rozmiaru dodatkowej pamieci
;pierwsze podejscie (oby dobre)
;najpierw zapamietuje komorki $0000 ze wszystkich 256 bankow w buforze, potem je zeruje
;testuje kazdego po kolei na zapisanie i odczytanie jakichs wartosci i oznaczam jako sprawodzony
;jesli nowy bank badzie mial w tym miejscu taka sama wartosc, to jest olewany
;(bo powinien miec zero jesli jest nowy). Potem odnawiam wartosci i wsio
;zreszta mozna (chyba) zalozyc, ze pamiec jest scisle ciagla, czyli mozna zatrzymac sie na pierwszym banku,
;ktory nie jest nowy
;ZWRACA:
;HighLinearBanks - numer ostatniego dobrego banku (0 gdy nie ma dodatkowej pamieci 255 gdy jest 16MB)
        !zn CountHighMem
CountHighMem
        stz vl0
        sep #%00110000
        !as
        !rs

;zapamietujemy
        ldx #$ff
        stx HighLinearBanks
        inx
.0      stx vl0+2
        lda [vl0]
        sta CntHMemBuf,x
        inx
        bne .0

;zerujemy
        stx vl0+2
        txa
.1      sta [vl0]
        inc vl0+2
        bne .1

;testujemy
        stx vl0+2
.2      lda [vl0]
        bne .nast
        lda #'S' ;prawdzony :)
        sta [vl0]
        cmp [vl0]
        bne .nast
        inc HighLinearBanks
.nast   inc vl0+2
        bne .2

;sprzatamy
.koniec ldx vl0+2
        dex
.3      stx vl0+2
        lda CntHMemBuf,x
        sta [vl0]
        txa
        beq .4
        dex
        bra .3
.4      rep #%00110000
        !al
        !rl
        rts