1

czytam, ze wstaznik stosu jest 9 bitowy z ustawionym na stale najstarszym bitem - innymi slowy d..a zbita.

no dobrze, mozna zapisac go nowa wartoscia i zrobic sobie 2 stosy w ramach 1 strony pamieci... ale to jeszcze nie to.

mamy rejest odpowiedzialny za przelaczanie bankow no i jest dobrze, a moze by tak jakis sprytny upgrade ktory:

pozwoli przelaczac TYLKO 1 strone pamieci? podczas gdy na szyne wystawiany jest adres z 1 stony pamieci to tak naprawde adresowana bedzie strona ustalona w jakims sprytnym rejestrze ?

dostalibysmy wtedy 255 stosow


zreszta na podobnej zasadzie z 0 strona pamieci - dostalibysmy niezlego speeda - wszystkie tablice na 0 stronach ;-)

dobra juz nie marudze, czekam na 65816

http://atari.pl/hsc/ad.php?i=1.

2

Na upartego to nie byłoby trudne - np. wrzucić port wejścia-wyjścia (np. drugie PIA) pod adres $d304 i bity sterujące przeznaczyć na wybór 1 z 256 banków strony zerowej i/lub strony 1 (stos). Ale napewno lepiej jest poczekać na 816 i w tym kierunku podążać ;)

3

na co tu czekac, przeciez 65816 jest ogolnie dostepny, czekac to mozemy za 14MHz 65816 by Pasiu co pewnie niedlugo bedzie oznaczac "czekać do usranaj śmierci"

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

4

Na dopałce Pasia nie wiem, czy nie będzie się bardziej opłacało korzystać z głównej pamięci niż ze strony zerowej. Odczyt mianowicie będzie jak zwykle trochę szybszy:

LDA zp: 3 cykle
LDA abs: 4 cykle
LDA long: 5 cykli

ale zapis za to wolniejszy:

STA zp: 10 cykli
STA abs: 11 cykli w banku 0 i 4 w pozostałych
STA long: 12 cykli do banku 0 albo 5 do pozostałych

KMK
? HEX$(6670358)

5

A po co wiecej stosow?
Jezeli masz az takie zagniezdzenie, da sie to latwo rozwiazac programowo i prawie automatycznie.
Na poczatku kazdej funkcji do ktorej JSRujesz dodajesz JSR manager_stosu
Ta funkcja z kolei sprawdza jak duzy jest aktualnie stos, i jezeli przekroczylismy pewien limit, przepisuje aktualny stos do wydzielonego obszaru pamieci, i podmienia adres powrotu funkcji wywolujacej, tak zeby wracala do specjalnej funkcji ktora przywraca stary stos.

: 404. Stopka not found

6

jesli programowo to mads udostepnia stos programowy

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

7

drac030 napisał/a:

LDA zp: 3 cykle
LDA abs: 4 cykle
LDA long: 5 cykli

ale zapis za to wolniejszy:

STA zp: 10 cykli
STA abs: 11 cykli w banku 0 i 4 w pozostałych
STA long: 12 cykli do banku 0 albo 5 do pozostałych

Rozumiem ze różnica wynika z tego, że odczyt jest buforowany, ale jak obliczyłeś te konkretne wartości?

8

Zakładam, że odczyt (mowa o pierwszych 64k) jest szybki, a zapis wolny. Skoro takie STA zp składa się z dwóch cykli odczytu i jednego cyklu zapisu, to będziemy mieli dwa cykle szybkie i jeden wolny. Skoro jeden wolny cykl równy jest ośmiu szybkim, więc mamy 2+8 = 10 cykli 14-megahercowego zegara.

KMK
? HEX$(6670358)

9

Może nie być tak idealnie. Nie wiem jak będzie działał F7, ale przy pesymistycznym i chyba rozsądnym scenariuszu dostęp do "wolnej" pamięci może być jeszcze wolniejszy: Szybki zegar będzie 14 MHz, wolny będzie z dzielnikiem 8, więc wolny cykl nie może zacząć się w dowolnym momencie, tylko gdy numer szybkiego cyklu będzie dzilił się przez 8. Jeżeli zaczniemy takie STA zp od cyklu zerowego, to pierwsze dwa będą szybkie, a trzeci będzie wolny i będzie musiał poczekać 6 cykli do "wyrównania" i dopiero będzie mógł wykonać się wolny, czyli 2+6+8 = 16 cykli. No oczywiście szybciej będzie jeśli cykl wolny nie będzie musiał czekać.

Pytanie tylko czy musi być te wyrównanie, czy nie, bo tak podpowiada mi tylko zdrowy rozsądek oraz to, że Pasiu opowiadał mi, że warp4 przy przejściu z szybkiej pracy do wolnej musi cykl odczekać.

10 Ostatnio edytowany przez drac030 (2006-05-29 18:41:27)

Trudno powiedzieć. Może będzie jak piszesz, czyli do 16 cykli. W każdym razie STA zp na pewno nie będzie szybsze niż te wyliczone przeze mnie 10 cykli, czyli będzie się wykonywać 2x dłużej niż zapis do wysokiej pamięci przez STA long. Ze stosem to samo. I to miałem na myśli. A jak będzie w praktyce, się zobaczy.

KMK
? HEX$(6670358)

11

Racja. Dlatego jak pisać dema, to najszybciej będzie wszystkie obliczenia robić na pamięci wysokiej i na końcu przepisać ekran (najlepiej za pomocą PEA) do pamięci podstawowej.
Na 65816 faktycznie można mieć stosów ile się chce, ale najbardziej bolesne jest to, że rejestr D mimo, że 16-to bitowy to nie pozwala zaadresować 65536 stron pamęci, tylko można ustawić sobie "direct page" od dowolnego adresu banku zerowego, co IMHO jest delikatnie mówiąc mało przydatne, szczególnie, że gdy młodszy bajt D jest niezerowy to operacja jest o takt dłuższa.  Może to pomoga w relokowalności, ale zysk z drugiej opcji byłby znacznie większy.