Atari

Zapomniane hasło? Poproś o członkostwo

Nowinki/News Archiwum/Archive

Translate to

Pojedynek Atari XL/XE i C64 z 2023-09-25 15:52 (14)
Time Wizard z 2023-09-20 20:29 (24)
TwiSTEr- nowa karta dla Atari STE z 2023-09-17 19:39 (3)
Zaproszenie na ATASCII Compo Edycja 3 2023 z 2023-09-10 20:23 (29)
Krakowskie Retrospekcje XI z 2023-09-08 22:08 (1)
Letnia edycja Silly Venture 2023 z 2023-08-19 11:27 (16)
Zakończyliśmy Środo-wisko Książkowe z 2023-07-28 08:47 (12)
Środo-wisko książkowe #6 z 2023-07-12 16:20 (7)
Sizecoding cz.2 - Gwiazda Śmierci z 2023-07-02 18:22 (23)
Środo-wisko książkowe #5 z 2023-06-28 06:23 (5)
Sizecoding cz.1 z 2023-06-25 16:25 (27)
Urodziny Atari Poland z 2023-06-24 01:16 (7)
Planeta Targ po raz trzeci z 2023-06-20 15:59 (2)
Wkrótce Decrunch we Wrocławiu z 2023-06-20 09:15 (2)
Niedzielne spotkania z 2023-06-17 21:06 (8)
KWAS #29 za nami z 2023-06-13 12:40 (10)
Starglider 2 na Atari ST/STE z 2023-06-12 23:31 (12)
Drugie "Środo-wisko książkowe" z 2023-06-06 13:49 (6)
Niedzielne spotkania z 2023-06-02 14:11 (1)
K.W.A.S. #29 w Katowicach z 2023-05-30 04:24 (14)

«« nowsze

starsze »»

Pomocnik/Helper

SFX-Engine w MAD Pascalu (3)
Narzędzie do tworzenia scrolli (10)
Kartridż Sparta DOS X (5)
Usprawnienia magnetofonu XC12 (11)
Konserwacja stacji dysków 1050 (19)
Konserwacja magnetofonu XC12 (13)
Nowe gry w 2020 roku (3)
Nowe gry w 2019 roku (35)
Nowe gry w 2017 roku (3)
Larek pokazuje (40)
Emulacja ZX Spectrum na VBXE (25)
Nowe gry w 2016 roku (7)
Nowe gry w 2015 roku (4)
Partycjonowanie karty SIDE (APT/FAT16/FAT32) (1)
BMPVIEW (34)
Atari ST dla opornych (74)
Nowe gry w 2014 roku (18)
Tritone engine (11)
QChan Engine (5)
Atari i monitor (1)

nowsze

starsze

HI SCORE CAFÉ

Gry/Games

0-9	A	B	C	D
E	F	G	H	I
!info	inne	J	K	L
Ł	M	N	O	P
Q	R	S	Ś	T
U	V	W	X	Y
Z	Ż

md5, sha (7-Zip, TUGZip)

"Old Towers" (Atari ST) opisał Misza (19)
Submarine Commander opisał Kaz (11)
Frogs opisał Xeen (0)
Choplifter! opisał Urborg (0)
Joust opisał Urborg (16)
Commando opisał Urborg (35)
Mario Bros opisał Urborg (13)
Xenophobe opisał Urborg (36)
Robbo Forever opisał tbxx (16)
Kolony 2106 opisał tbxx (2)
Archon II: Adept opisał Urborg/TDC (9)
Spitfire Ace/Hellcat Ace opisał Farscape (8)
Wyspa opisał Kaz (9)
Archon opisał Urborg/TDC (16)
The Last Starfighter opisał TDC (30)
Dwie Wieże opisał Muffy (19)
Basil The Great Mouse Detective opisał Charlie Cherry (125)
Inny Świat opisał Charlie Cherry (17)
Inspektor opisał Charlie Cherry (19)
Grand Prix Simulator opisał Charlie Cherry (16)

«« nowsze

starsze »»

Aktualizacja: 2024-03-16
Liczba katalogów: 8377, liczba plików: 36679
Zmian katalogów: 0, zmian plików: 0

0-9	A	B	C	D
E	F	G	H	I
J	K	L	M	N
O	P	Q	R	S
T	U	V	W	X
Y	Z	inne

Wewnętrzne/Internals

Organizowanie imprez Atari - dyskusja
Atari demoscene database - dyskusja
Colony Mobile - dyskusja
Colony Mobile - projekt
Statystyki

Nowinki tworzone dzięki CuteNews

Sizecoding cz.1

Kamil "Gorgh" Trzaska napisał:

Z racji tego, że ostatnio było na AtariOnline.pl mniej artykułów o tematyce programistycznej, to postanowiłem napisać coś, co mogłoby z tego zakresu znaleźć uznanie wśród czytelników portalu. Spośród rzeczy, na których się znam, jest programowanie w limicie rozmiaru pliku czyli po angielsku sizecoding. Ten sposób pisania programów zakłada optymalizację kodu do określonej wartości, na przykład 128 bajtów, 256 bajtów, 1024 bajtów (1 Kb) czy 16 kilobajtów. W tym artykule skupię się na dwóch pierwszych typach sizecodingu, z racji tego, że wymagają one największego kombinowania pod względem optymalizacji.

(zdjęcie: Mphobic/PTODT)

1. Strona zerowa
Pierwszą rzeczą, którą zazwyczaj się robi, jest umieszczanie kodu programu na stronie zerowej. Jest to pierwsza z kolei strona pamięci, o adresach od $0000 do $00ff (szestnastkowo). Plusem tej strony jest to, że odwołując się do lokacji tam umieszczonych zazwyczaj używa się tylko jednego bajtu zamiast dwóch. Dla przykładu taki rozkaz używa dwóch bajtów:


LDA $88

zaś tutaj to już trzy bajty:


LDA $188

Instrukcje, które operują na komórkach na stronie zerowej również szybciej się wykonują. Zazwyczaj przyjmuje się, że bezpiecznym jest ładowanie programu od komórki $80, czyli od połowy strony zerowej. Poniżej tej wartości znajdują się zmienne systemowe i nadpisanie ich podczas ładowania programu może zawiesić komputer. Jak łatwo się domyślić, program, który ma 256 bajtów nie zmieści się w całości na rzeczonej zerowej stronie, więc część programu będzie umieszczona w pamięci stosu Atari, lecz zazwyczaj w niczym to nie przeszkadza, ponieważ stos standardowo zaczyna się od komórki $1ff, czyli końca pierwszej strony, i powiększa się w dół czyli w kierunku $100, ale prawie nigdy podczas prawidłowego działania komputera nie osiąga wartości $1c0, czyli 3/4 strony.

2. Użycie rejestru X

Jednym z udogodnień programowania rozmiarowego jest możliwość zastosowania indeksowania rejestrem X, który zastosowany do wartości na stronie zerowej zajmuje tylko dwa bajty zamiast trzech. Dla przykładu ta instrukcja zajmuje dwa bajty:


LDA $c0,x

podczas gdy ta już trzy:


LDA $c0,y

Przydatne jest to, jeśli w naszym programie używamy nie tylko kodu, ale również danych, na przykład współrzędnych linii, łańcuchów tekstowych albo wartości muzycznych, wtedy umieszczając je na stronie zerowej możemy oszczędzić parę bajtów.

3. Recykling wartości bajtów

Inną, często stosowaną, metodą zmniejszenia kodu jest powtórne używanie danej komórki na stronie zerowej. Jeśli w pierwszej części programu wynikiem działania były określone wartości w pamięci (możemy to podejrzeć w debuggerze emulatora) i tak się składa, że jedna z komórek ma wartość taką, jakiej potrzebujemy, to możemy jej użyć bez inicjowania nowej zmiennej. Dla przykładu jeśli komórka $b0 ma wartość $40, to zamiast w programie stosować:


LDA #$40
STA zmienna
[...]
DEC zmienna
BNE loop

możemy bezpośrednio użyć zmiennej bez inicjowania jej:


DEC $b0
BNE loop

Powyższy kod zmniejsza zawartość komórki i skacze do pętli "loop" dopóki zmienna nie osiągnie wartości zero.

4. Unikanie CLC i SEC gdzie się da

Jednym z uroków procesora 6502 jest to, że dodawanie i odejmowanie wykonywane są ZAWSZE z pożyczką z jednobitowej wartości flagi carry procesora. Procesory posiadają odrębny rejestr flagowy, który przechowuje dodatkowe informacje o wykonywanym programie. Flaga carry jest ustawiania, gdy wynik dodawania przekroczy wartość 255, zaś jest kasowana, gdy wynik odejmowania jest mniejszy od zera. W przypadku innych procesorów ośmiobitowych flaga carry jest ustawiana w obu wspomnianych przypadkach, jednak w przypadku 6502 jest inaczej, co powoduje u mnie potrzebę zastanawiania się, jak się ta flaga zachowa przy każdej operacji
dodawania/odejmowania. Ale do rzeczy: jeśli nie zależy nam na dokładności operacji tak bardzo, to zamiast:


LDA zmienna
CLC
ADC #$4
STA zmienna

możemy zrezygnować z jednego rozkazu:


LDA zmienna
ADC #$4
STA zmienna

Podobnie można się zachować, gdy mamy pewność, że wcześniejsze działanie programu ustawiło bądź skasowało flagę carry (na przykład przez rozkaz porówania CMP/CPY/CPX, który zachowuje się jak odejmowanie pod względem ustawienia flag). Zazwyczaj sprawdza się to w praniu, czyli gdy już mamy gotowy program to usuwamy CLC/SEC z różnych miejsc i patrzymy czy ma to znaczący wpływ na działanie kodu. Może się zdarzyć, że flaga jest zawsze ustawiona, więc zamiast:


LDA zmienna
ADC #$4
STA zmienna

możemy swobodnie zastosować:


LDA zmienna
ADC #$3
STA zmienna

Co da nam to samo, ponieważ pożyczka z flagi carry to dodatkowa jedynka.

5. Używanie niepublikowanych procedur systemowych

Większość komputerów linii XL/XE wyposażonych jest w system operacyjny rewizji B. Oznacza to, że kod, który będzie opierał się na procedurach zawartych w ROM-ie, zadziała na 90% komputerów Atari. Jest to znośny margines, biorąc pod uwagę fakt, że stosowanie tych procedur daje ogromne pole do zmniejszenie kodu. O procedurach systemowych więcej można poczytać w tym poście xxl-a. W ten sposób można za pomocę 5 bajtów uzyskać dowolny systemowy tryb graficzny, systemowo stawiać piksele o danym kolorze, jak również rysować linie.

6. Stosowanie niewielkich generatorów sinusa/cosinusa

Wiele efektownych programów na 8-bit korzysta z generowanych tablic sinusów. Tablica taka pozwala na pokazanie płynnego ruchu, płynnych kształtów oraz różnego typu owali, gdyż sinus jest po prostu nielinionym przyrostem wartości, który tworzy płynną krzywą. Na chwię obecną najmniejszymi procedurami generującymi sinusa są zoptymalizowane procedury Koali, które zajmują naprawdę niewiele mniejsca.

7. Podsumowanie

Sizecoding pozwala na realizowanie bardzo wielu pomysłów w niewielkim rozmiarowo programie. W moim przypadku około 90% moich pomysłów na efekty dało się zmieścić w tym rozmiarze. Co ciekawe, optymalizacja kodu wydaje się nie mieć końca, ponieważ prawie zawsze udaje się zmniejszczyć kod o ten jeden czy dwa bajty. Oczywiście jest to jedynie subiektywne odczucie, ponieważ w pewnym momencie kończą się realne możliwości zmniejszania kodu. Można jednak założyć, że kod, który początkowo ma 400 bajtów, de facto spokojnie zmieści się w 256 bajtach. Ilmenit podejmował próby stosowania pakowania programów 256 bajtowych, jednak nie przyniosło to skutków, dlatego można założyć, że ten rozmiar programu raczej nie da się spakować. Zachęcam wszystkich do spróbowania swoich sił w tej dziedzinie programowania i pozdrawiam wszystkich czytelników.

2023-06-25 16:25 by Kaz

komentarzy: 27

gorgh @2023-06-25 17:54:55

Dzięki Każ za sformatowanie tekstu i publikację

Kaz @2023-06-25 18:01:01

Cała przyjemność po mojej stronie - artykuł bardzo ciekawy, dobry punkt startu dla chętnych na sizecoding!

mar_tec @2023-06-25 19:46:21

Dziękuję, super pomysł i artykuł.
Proszę o więcej jeżeli chodzi o programowanie.
Może zrobicie kurs programowania, coś na wzór tego z Tajemnic Atari?
Wydaje mi się, że mogłoby to pomóc niejednemu i zachęcić do tworzenia programów na Atari. Jeszcze raz serdecznie dziękuję.

Zenon @2023-06-25 21:48:22

SUPER....
Czyta się i jednocześnie główkuje z największą przyjemnością i ciekawością.
Wraca klimat wczesnych lat 90-siątych, i tego co Tajemnice Atari i tylko one zdradzały co w środku "siedzi"

Adam @2023-06-25 22:25:23

Gorgh, dzięki za artek :)

bob_er @2023-06-25 23:57:41

Fajny pomysł na tekst, choć przydałby się jakiś przykład. Ale to już część druga :).

mkolodziejski @2023-06-26 06:17:35

wow. Gorgh! Zawsze Ciebie dobrze się czyta, a techniczne artykuły - od specjalisty dla jakichś, nie przymierzając, lamerów (no pun intended) takich jak ja, to melodia na moje uszy.

Przydałby się przykład tej metody - choćby na github, bo mimo że "jak" jest najważniejszym czynnikiem, to chciałbym się dowiedzieć "po co" stosować tę technikę optymalizacji, w jakich sytuacjach ona będzie nieskuteczna, a może nawet podpowiedź - jak o tym zdecydować.

Jednym słowem - brawo!!! a drugim - narobiłeś mi apetytu na drugą część, bo osobom nieasemblerowym, pojawić się może więcej pytań niż odpowiedzi, jak w moim przypadku.

gorgh @2023-06-26 07:27:00

Dzięki za pozytywny odzew, w takim razie powstanie część druga. Co do kursu assemblera to swego czasu napisałem podręcznik programowania w tym języku, może na AOL dałoby radę go opublikować.

JacekPiast @2023-06-26 08:46:15

Bardzo fajny tekst, dobrze się czyta. Przypomniały mi się czasy Bajtka i czytanie tekstów o programowaniu, których nie rozumiałem ale pozwalały obcować z czymś magicznym ;) . Tutaj jest na tyle logicznie, że rozumiem poszczególne rozdziały (tak mi się wydaje) ale na razie nie potrafię z tego korzystać bo nie znam assemblera. W te wakacje jednak chcę się trochę pouczyć assemblera Atari i ZX Spectrum. Mam nadzieję, że wyjdzie bo od ponad roku się zbieram ;)

maly_swd @2023-06-26 09:18:34

Bardzo fajny artykuł, miło się czyta i przypomina stare dobre czasy.

Caesar @2023-06-26 09:32:50

Również bardzo dziękuję. Może gdzieś w końcu przeskoczy odpowiednia zapadka i z etapu "coś chcę zrobić", przejdzie do "coś zrobię'.

crrn @2023-06-26 15:17:17

fajne, ale coś mi się nie zgadza... wg mnie nie ma instrukcji typu
lda $c0,y
jest za to lda ($c0),y ale ta też ma 2 bajty
więc albo czegoś nie zrozumiałem, ale jest pomyłeczka.

gorgh @2023-06-26 15:24:51

ale wydaje mi się, że stronę zerową można adresować rozkazem 3 bajtowym lda $xxxx,y

bob_er @2023-06-26 17:36:31

@crrn, chodzi o to, że nie ma rozkazu 'lda zp,y' (który miałby 2 bajty) jest tylko 'lda abs,y' (który ma 3 bajty). asemblery widząc zapis 'lda $c0,y' robią z tego 3bajtowy 'lda $00c0,y'.
'lda (zp),y' istnieje, ma 2 bajty ale inny sposób działania.

szeryf @2023-06-26 19:39:55

@Gorgh, mega konkret plus fajne linki, dzięki.

Cuzz @2023-06-26 20:44:20

a możee tak USR albo PUT?

as.. @2023-06-26 22:59:47

Super artykuł !

Krzys @2023-06-27 09:44:03

Ładnie. Dziękuję.

jhusak @2023-06-27 09:53:00

Jeszcze czasem się przydaje podejście: ustawiam znaczniki przez np. cmp (a/x/y), potem coś robię, co nie zmienia znaczników (np sta), a następnie robię jakieś bcc czy bvs.

SuN @2023-06-27 14:54:04

Można też popatrzeć na takie cuda github.com/jhusak/Atari8bitWorm256
github.com/FreddyOffenga?tab=repositories
github.com/sebastian-pawlak
github.com/ilmenit/sizecoding

NN @2023-06-27 18:03:56

Hm... Zdaje się, że artykuł wzbudził zainteresowanie niezbyt niewielu...

Gniewosz Niezbyt-Niewiel @2023-06-27 21:11:28

Mojego zainteresowania nie wzbudził.

Rozyk @2023-06-28 23:15:32

A moje wzbudził w dwójnasób.

Kaz @2023-06-29 08:06:58

Będzie ciąg dalszy! :)

Święty @2023-06-29 08:52:58

Używanie samomodyfikującego się kodu na stronie zerowej to kolejna optymalizacja :P

SuN @2023-06-29 15:31:53

no ba :)