1

Temat: pomysl na nowy kompilator 6502

Wstęp

CPU6502 nie ma możliwości bezpośredniego odwołania się pod konkretny adres dodatkowej pamięci (XMS) jak jest to w przypadku CPU65816. Potrafi maksymalnie zaadresować 64KB pamięci, dostęp do pamięci rozszerzonej realizowany jest przez przełączanie 16KB banków w obszarze $4000..$7FFF. Rejestr PORTB ($d301) jest odpowiedzialny za włączenie konkretnego banku pamięci w w/w obszar.

Założenia.

Aby program mógł działać w pamięci XMS będzie potrzebował kilka krótkich procedur i buforów umieszczonych poza obszarem $4000..$7FFF. Procedury te będą przełączały banki pamięci, dokonywały skoku.

Kompilator przestawia się w tryb pracy z dodatkowymi bankami pamięci (banked) po napotkaniu mnemonika BLK. Po napotkaniu tego mnemonika licznik banków zostaje zwiększony (defaulf=-1), a adres generowanego kodu ustawiany jest na $4000. Jeśli podczas kompilacji zostanie przekroczony adres $7FFF kompilacja zostaje przerwana i zasygnalizowany zostaje błąd przekroczenia dozwolonego obszaru. Aby uniknąć błędu przekroczenia dozwolonego obszaru należy ponownie umieścić mnemonik BLK w programie.

W trybie 'banked', podczas kompilacji wszelkie rozkazy skoków i adresowania będą sprawdzane czy nie odwołują się do obszaru o innym numerze banku. Odwołanie do obszaru o innym numerze banku będzie traktowane jako błąd i odpowiednio sygnalizowane.

Wyłączenie trybu 'banked' nastąpi po napotkaniu mnemonika ORG i adresu spoza zakresu $4000..$7FFF.

Skok do obszaru o innym numerze banku będzie możliwy tylko w trybie 'banked' przy pomocy dwóch mnemoników JML (jump long) oraz JSL (jump subroutine long). Jako że tylko CPU65816 posiada sprzętową obsługę JML i JSL, w przypadku 6502 będzie musiała zostać wykonana dodatkowa procedura. I tak napotkanie mnemonika JML lub JSL, każdorazowo spowoduje zastąpienie go następującym fragmentem kodu:

JML

        jsr ___pushAXY
 
        lda tablica_bankow     ; odczytanie kodu banku obszaru z tablicy
        ldx < $xxx             ; wyliczony adres 
        ldy > $xxx
        jmp ___jml

JSL

        jsr ___pushAXY
 
        lda tablica_bankow     ; odczytanie kodu banku obszaru z tablicy
        ldx < $xxx             ; wyliczony adres 
        ldy > $xxx
        jsr ___jsl

* --- jump long --- *

___jml  stx ___jmp+1    ; modyfikacja adresu ___jmp
        sty ___jmp+2
        jsr ___pullAXY
___jmp  jmp $ffff       ; skok

* --- jump subroutine long --- *

___jsl  pha             ; zapamietanie rejestru regA
        lda $d301       ; zapamietanie kodu poprzedniego banku
        sta ___bank
        pla
        sta $d301       ; wlaczenie banku
        stx ___jmp+1    ; modyfikacja adresu _JSR
        sty ___jmp+2
        jsr ___pullAXY  ; odczytanie wartosci z rejestrow A,X,Y
___jmp  jsr $ffff       ; wywołanie procedury
        pha             ; powrót z procedury, zapamiętanie regA
        lda #0          ; przywrócenie kodu poprzedniego banku
___bank equ *-1
        sta $d301       ; włączenie poprzedniego banku
        pla             ; zwrócenie regA
        rts             ; kontynuowania programu w dodatkowym banku

* --- push A,X,Y --- *

_pushAXY equ *
        sta ___regA     ; zapamiętanie wartości rejestrów
        stx ___regX
        sty ___regY
        rts

* --- pull A,X,Y --- *

     
___pullAXY equ *        ; oddanie wartości rejestrów
        lda #0
___regA equ *-1
        ldx #0
___regX equ *-1
        ldy #0
___regY equ *-1
        rts

Jeśli posiadamy 16-bit CPU kod generowany przez kompilator może być pozbawiony tych procedur i zastąpiony konkretnym kodem JML, JSL.

I tak ogolnie przedstawia sie pomysl na nowy kompilator 6502, co Wy na to ?

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

2

Odp: pomysl na nowy kompilator 6502

Jak planujesz pisać nowy produkt, to prosze Cię bardzo - dodawaj taki ficzer.
Ale nie ma sensu pisanie nowego asma tylko po to.
Poza tym (przynajmniej u mnie) rzadko się zdarza, że korzystam z kodu będącego naraz w większej ilości banków, oprócz oczywiście auto-generowanego kodu, ale dla niego Twoje rozwiązanie raczej nic nie pomoże.

Ogólnie: można, ale po co? Więcej roboty ze zrobieniem tego niż pożytku.

PS. zwyczajowo, na coś takiego się mówi 'assembler', kompilator to raczej z języka wysokiego poziomu do asma. Ale, że nie jest to ścisła klasyfikacja, to się nie czepiam :)

: 404. Stopka not found

3

Odp: pomysl na nowy kompilator 6502

W sumie popieram Eru. Jak dla mnie nie ma sensu. Szkoda roboty, ktora mozna wlozyc np. w menadżer plikow... ;)

4

Odp: pomysl na nowy kompilator 6502

albo w linker na całą pamięć posiadaną prze usera - też pomysł chyba upadł, co???  :?

I Ty zostaniesz big endianem...

5

Odp: pomysl na nowy kompilator 6502

zaleta takiego asemblera/kompilatora mialaby byc wlasnie mozliwosc swobodnego napisania duzego programu, z full wypas bajerami, nie trzeba martwic sie gdzie zmiescic ekran, dane, duzy bufor bo podczas asemblacji zostanie to automatycznie podzielone na 16KB fragmenty i niezaleznie od aktualnej konfiguracji pamieci dodatkowej (bo w kodzie wynikowym kody bankow nie bylyby podawane przez 'lda #$fe' tylko jako odwolanie do tablicy 'lda tablica_bankow+4') zostanie zaladowany i uruchomiony

oczywiscie warunkiem koniecznym musialoby byc istnienie konkretnej ilosci dodatkowych bankow, tyle ile wymaga dany program

z poziomu kazdej procedury mieszczacej sie w dodatkowym banku ($4000..$7FFF) bylaby mozliwosc adresowania obszarow $0000..$3FFF i $8000..$FFFF, w ten sposob przekazywane bylyby dane pomiedzy bankami jesli jest taka potrzeba, oczywiscie troszczy sie o to uzytkownik

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

6

Odp: pomysl na nowy kompilator 6502

Rozkazy JSL i JML w 65816 dotyczą skoków poza pierwsze 64kB, a nie do banków, więc tutaj nie znajdą zastosowania. Niewątpiwie jednak jego 16-bitowe rejestry mogą skrócić i przyspieszyć opisane procedury.

Zamiast pisać nowy asembler, można ułożyć makra dla dowolnego makroasemblera.

Preferowany MAE ze względu obsługę ficzerów 816-tki, ale nie tylko:
ˇ MAE potrafi zmieniać wartości etykiet w czasie asemblacji, co może być przydatne dla zapamiętywania numeru banku:

_bank.no = -1      ; $FFFFFF - 24-bit!
    set _bank.no = _bank.no+1

ˇ Makra MAE, w czasie asemblacji, wstawiane są jako listing do źródła i dopiero wtedy kompilowane. Dzięki temu można pokombinować z dynamicznym tworzeniem etykiet, a nawet kodu (!) co jest istotne przy odwołaniach pomiędzy bankami:

!!!makro .md
       ...
bank:1 = :2
       ...
       .em

Jeśli teraz wywołamy makro makro z parametrami np. 0 i $FF, to asembler utworzy etykietę bank0 o wartości 255, której wartość można później zmieniać!
ˇ MAE rozpoznaje lokalne etykiety makra (nazwa poprzedzona trzema kropkami - ...local) co chroni przed błędami typu Label defined twice.
ˇ Nie będę się już tutaj rozwodzić nad asemblacją warunkową, ale przy tego typu operacjach jest ona niezbędna.
Dołączam się więc do swych przedmówców.

Po co wyważać otwarte drzwi? :D

Zawsze mam rację, tylko nikt mnie nie słucha.

7

Odp: pomysl na nowy kompilator 6502

mimo wszystko jak dla mnie pomysł nawet ciekawy...

8

Odp: pomysl na nowy kompilator 6502

przyklad Lizard'a niezle przekombinowany :)

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

9

Odp: pomysl na nowy kompilator 6502

Co masz na myśli, bo nie wiem czy mam się obrazić? ;)

Może i jest to kombinowanie. Na pewno jednak mniejsze niż pisanie pięćdziesiątego asemblera. Poza tym wygląda to skomplikowanie, ale takie nie jest. Skomplikowanie mogą wyglądać same makra, ale ich stosowanie jest bajecznie proste.

Zawsze mam rację, tylko nikt mnie nie słucha.

10

Odp: pomysl na nowy kompilator 6502

Pomysl z makrami bardzo mi sie podoba, szczegolnie, ze wlasnie skonczyla mi sie systemowa pamiec w Scorched Earth a chcialem, zeby gra sie odpalala z systemu i dzialala w miare "czysto".

Ale tak naprawde, to za...stym pomyslem byloby zaimplementowanie takiego mechanizmu w CC65 z jakim takim jeszcze hakiem, zeby program wykrywal, ktore banki moze zajac, a ktore sa nie do ruszenia (bo siedzi tam np. ramdysk albo inna sparta).

Jakby cos takiego zrobic w CC65 to dopiero sie otwieraja mozliwosci..... Az sie slinie.... 1.000.000 utili z unixa do przekomplikowania... gry, pakiery, cuda na kiju.... (wiele cudow na kiju nie uzywa jakichs wymyslnych bibliotek, ale tylko stdio.h i juz)

http://www.5oft.pl/

11

Odp: pomysl na nowy kompilator 6502

a czy MAE jest na PC ?

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

12

Odp: pomysl na nowy kompilator 6502

Tak, ale wymaga dodatkowego wsparcia w postaci Atari 800Byx'ow. :lol:

Zawsze mam rację, tylko nikt mnie nie słucha.

13

Odp: pomysl na nowy kompilator 6502

pomysl imho fajny - inaczej - godny poswiecenia czasu bebego ;)

14

Odp: pomysl na nowy kompilator 6502

albo w linker na całą pamięć posiadaną prze usera - też pomysł chyba upadł, co???

pierwsze slysze, o co w tym chodzilo ? o linker dla cc65 ?

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

15

Odp: pomysl na nowy kompilator 6502

celem aluzji był kolega lewiS akurat - on wie osssochozzii... :P

I Ty zostaniesz big endianem...

16

Odp: pomysl na nowy kompilator 6502

No wiem, wiem. Moze kiedys to skoncze... ;)
Mial byc linker dla Atari wykorzystujacy cala dostepna pamiec. Oczywiscie z mozliwoscia okreslenia, ktore banki maja byc wykorzystane. Projekt jak narazie ukonczony w 50%.

17

Odp: pomysl na nowy kompilator 6502

A czy zrobił już ktoś assembler wykorzystujący nielegalne rozkazy? Taki QA 2.0 by się może przydał.
A jakie demka wykorzystują te nielegele ( jeśli takie są) ??

18

Odp: pomysl na nowy kompilator 6502

a po co? poza tym można zrobić mini-tablicę z kodem konkretnego rozkazu i wykonać skok do niego... (nie pamiętam, czy w środku kodu można też posiać dowolny kod znaku odpowiadający danemu nielegalowi, być może...)

A w ogóle użycie nielegali wyklucza możliwość odpalenia "tego czegoś" na "nowym ROMie" (o 65816 już nie wspomnę).

I Ty zostaniesz big endianem...

19

Odp: pomysl na nowy kompilator 6502

E, no, co wy, TeBE postanowił wygrać następny ABBUC contest użytkiem, a nie grą. :D

A tak poważnie, to TeBe o ile wiem i tak pisze nowy assembler, więc dodanie czegoś-tam przy okazji to dla niego pestka (choć może duża).
Zasadnicze pytanie to: ile osób chciałoby potem tego używać. Większość ludzi jest konserwatywna i dotąd preferuje stare, proste QA. Może jakaś ankieta: "łe tam/mógłbym użyć/wypas". :D

A TeBe pewnie i tak zrobi ;) choćby dla siebie.

20

Odp: pomysl na nowy kompilator 6502

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.

21

Odp: pomysl na nowy kompilator 6502

Na 65c816 z odpowiednią ilością pamięci (15 MB na przykład) można by już pokusić się o gcc.

KMK
? HEX$(6670358)

22

Odp: pomysl na nowy kompilator 6502

A jakie demka wykorzystują te nielegele ( jeśli takie są) ??

JoyRide - któraś tam część z plotterem na dole - objawy; plot stoi w miejscu, demko leci dalej.

Prawdopodobnie TheLastStarflighter - to już stara (i niezła) gierca;- lecz to trzeba zweryfikować - więc prośba do posiadaczy 65c816 o sprawdzenie wspomnianego fenomenu - tym bardziej, że gierka pochodzi z bodaj 1983 r. W każdym bądź razie - u mnie na 816 gierka nie odpali..

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

23

Odp: pomysl na nowy kompilator 6502

tzn. tak - na moim XEGS-ie, na którym jak coś nie łaziło na czymś to na nim nie łaziło na pewno, to ztcp Last Starfighter łaził bez problema.

Nie łaził natomiast Muad'Dib i jeszcze cośtam Hurka oraz giercun pt. Bounty Bob Strikes Back.

I Ty zostaniesz big endianem...

24

Odp: pomysl na nowy kompilator 6502

Miker - wiem, że bez problema - bo zapewne miałeś tam 6502. Chodzi mi o tesy na 65c816 pod kątem TheLast..., oraz innych rzewczy z którymi mogą wystąpić potencjalne problemy przy odpaleniu...; lecz i tak - z czego widze; problemy tego typu są dość sporadyczne i jednostkowe.

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

25

Odp: pomysl na nowy kompilator 6502

Będe miał spowrotem monitor to sprawdze na moich dwóch atarkach czy one działają pod tym kątem, aż sam jestem ciekaw.