Pierwsze kroki w Pasmo

[RafalM]

Bo może rzeczywiście tak się nie robi.

Jeśli stworzyłeś kod który przestajesz ogarniać to może czas go przerobić tak by robił to samo ale był prostszy i bardziej uporządkowany.

Fachowo się to nazywa refaktoryzacja kodu

[tdu]

Chyba już błąd znalazłem, czeka mnie teraz kolejna refaktoryzacja 

[tdu]

No i gotowe, tym razem to dłużej trochę trwało, ale w końcu się udało.

Teraz jeszcze zmiana plansz, wykorzystanie większej części ekranu.
może jakieś lepsze dźwięki ... ta zabawa nie ma końca.

Dla kropki to jest wyzwanie, ale gdyby to było coś więcej niż kropka,
nie mam pomysłu, musi być na to jakaś chytra sztuczka.
Procesor nie dałby sobie rady z animacją zbioru kropek.
Trzeba by to jakoś hurtowo zrobić. 

[RafalM]

Procesor nie dałby sobie rady z animacją zbioru kropek.

Jak mądrze zrobić to dałby

Ale rozumiem że chodzi ci o sprajty. Więc masz rację,sprajtów się nie składa z pojedynczych kropek.

Jak coś kopiujesz na ekran to tak naprawdę zawsze nie jedną kropkę tylko 8 kropek (zapalonych lub zgaszonych) czyli bajt.

Spectrum nie ma sprzętowych sprajtów. Jak chcesz na ekranie wyświetlić jakiegoś ludka to musisz do pamięci ekranu przekopiować wszystkie bajty składające się na tego ludka. Innej opcji nie ma.

[tdu]

No tak, właśnie to przerabiałem, żeby wyświetlić poruszającą się
kropkę trzeba odpowiednie bity zapalać i gasić.
Chociaż pierwsza wersja mojego programu właśnie na całych
bajtach operowała, wpisywałem $ff.

Oszczędności wymusiły taką organizację ekranu.
Wszystko jeden wielki kompromis rozdzielczości (jakości) do ceny.

[tdu]

czy takie polecenia są sobie równoważne:

1.     ld hl, $4020

2.    ld hl, 16416

3.    ld h, $64      ld l, $20

4     ld h, $64       ld l, 32

bo miałem przypadek żę wersja 4 działa a 1 i 3 nie.
(pasmo błędu w żadnej wersji nie wyrzuca)

[Tygrys]

1 i 2 są tożsame.

3 i 4 również.

To że masz gdzieś jakiś błąd, może wynikać stąd, że gdzieś mogłeś pomieszać zapis liczb w dziesiętnym i szesnastkowym.

[tdu]

A 1i2  z  3i4  chyba też.

W takim razie muszę jeszcze w kodzie pogrzebać.

[matofesi]

1 i 2 nie są tożsame z 3 i 4. W tych drugich do H ładujesz $64 czyli 100 zamiast $40 czyli 64.

[tdu]

To żle napisałem w 1, powinno być $6420 czyli dziesiętnie to samo co w 2, 16416

Już mi się oczywiste rzeczy mylą, muszę trochę od asemblera odpocząć.
Dema nie będzie 

[RafalM]

To żle napisałem w 1, powinno być $6420 czyli dziesiętnie to samo co w 2, 16416

To nie jest to samo. Cały czas ci się myli 64 i $64 czyli 64 i 100.

Napisałem kiedyś dla siebie prosty programik okienkowy do przeliczania z szestnastkowego na dziesiętny i vice versa.
Wrzucę go tutaj wieczorem, może się komuś przyda.

[tdu]

Znowu jakiś dziwny efekt wyskakuje mi po asemblacji.
Najprostszy program, tylko zeruje akumulator

org 40000
xor a
di
halt
ret
end 40000

pasmo generuje kod prawidłowo

natomiast debugger  emulatora, zaczyna prace nie od 40000
a od 39999

wiec na poczatku nie ma juz xor a, a za to jest ld a,175
więc dłuższy program pójdzie w krzaki.

Na Spectaculatorze i Spinie jest to samo.


 

[Tygrys]

Debugger w ZX Spin czasami głupieje, bo chce być inteligentny ;-) Jeżeli masz jakąś wartość w 39999 i jest nim opcode dla LD A,xx (dec: 160, hex $A0),  to kolejną bajt traktuje jako argument dla tegoż (XOR A ma opcode 175).

Program zadziała prawidłowo, bo on na adresie 40000 będzie mieć XOR A....

Nie wiem jak zachowują się inne debugery.

[tdu]

Zauważyłem że instrukcja NOP po org 40000 porawia sytuację.
A te bajty na dole to chyba stos z basica.
Powiniem być niżej ustawiony.

[Phonex]

Debugger w ZX Spin czasami głupieje, bo chce być inteligentny ;-)

Bo jest uparty, a nie inteligentny.
Przy przewijaniu w górę pamięci robi dobrze, zwiększając adres początku deasemblacji o tyle bajtów ile zajmowała instrukcja w pierwszej linii (bo inaczej się nie da!). Ale przy przewijaniu w dół pamięci powinien zmniejszać adres początku deasemblacji o 1, a nie o długość najdłuższej sensownej instrukcji (jak zdaje się robi).
MAD monitor na ZX-a robi to dobrze. Efekt uboczny jest taki, że przy skrolowaniu w dół pamięci w pierwszej linii ciągle się kotłuje, bo instrukcje się zmieniają. Ale przynajmniej jest jedno ustawienie pokazujące poprawny program, a w Spinie nie ma.

Ta cecha jest wkurzająca, bo jeśli (jak w przytoczonym programie) ustawi się pułapkę na 40000, to nie będzie jej widać! Często w takim przypadku wpisuję w to miejsce NOP debuggerem.
Ale może nie było innego rozwiązania, skoro wpisywany adres początkowy deasemblacji nie jest na górze strony, tylko w połowie?


PS. LD A,xx to 62 ($3E). To jest, zdaje się, znacznik końca stosu BASICowego GO SUB.