Pierwsze kroki w Pasmo

[Tygrys]

To ja podziele się jeszcze jednym usprawnienem.

Jeżeli mamy coś takiego:

Kod: [Zaznacz]

ZZZ:
    ....

    CALL   xxxxxx
    RET

to śmiało można to zamienić na

Kod: [Zaznacz]

    JP   xxxxxx

A dlaczego tak? Bo CALL odkłada na stos adres, który wskazuje na RET. RET to taki odpowiednik POP PC (taka instrukcja nie istnieje, w razie wątpliwości). Możemy zatem skorzystać z RET w procedurze xxxxxxx. Takie rozwiązanie daje nam 1 bajt i 17 taktów oszczędności.

[RafalM]

To ja podziele się jeszcze jednym usprawnienem.

A to ci powiem Tygrysie że jak tak nie robię.

Masz absolutną rację co do oszczędności w bajtach i taktach ale razi to jakoś moje prywatne poczucie piękna    Procedura powinna się kończyć przez RET i już 

[Phonex]

Ja też.
To znaczy robię tak, ale tylko jak oszczędzam miejsce (lub takty).

[tdu]

Odnośnie dyskusji na temat błędu wskutek złego umieszczenia deklaracji danych.
Uważam że asembler powinien z automatu wyrzucać je na koniec programu tak
żeby nie powodowało to błędu.
Programista pisze deklaracje DEFB gdzie mu wygodnie, a asembler powinien to
wstawić tam gdzie trzeba.

Do mojego programu dorzuciłem dźwięk przy kolizji,
zastosowałem taką procedurę:

Kod: [Zaznacz]

sound1 LD bc,200
pet1
  ld a,29
  out (254),a
  call time4
  ld a,6
  out (254),a
DEC bc
LD a,b
OR c
JP NZ,pet1
ret

time4 robi dodatkowe opóźnienie
a wartości 6 i 29 dobrałem tak żeby uzyskać
określone kolory

efekt w załączniku.

Zdominowałem ostatnio forum swoimi wpisami,
ale wyjeżdżam na długi weekend i macie mnie z głowy
do przyszłego tygodnia.

Nie ma to jak rowery.

[Phonex]

"DEFB" to nie jest deklaracja danych.
To po prostu sposób na wpisanie liczb. Są tam gdzie programista je umieści. Mogą być wszystkim, również np. częścią samomodyfikującego się programu.

Nie ma w asemblerze rozdzielenia na dane i program. Wszystko ustala się samemu.

[RafalM]

Uważam że asembler powinien z automatu wyrzucać je na koniec programu tak
żeby nie powodowało to błędu.
Programista pisze deklaracje DEFB gdzie mu wygodnie, a asembler powinien to
wstawić tam gdzie trzeba.

Masz naleciałości z języków wyższego poziomu.

Jak w Basicu czy w C napiszesz int x=1 to zwykle cię dalej nie obchodzi gdzie ten x jest przechowywany bo dba o to kompilator i o późniejszy dostęp do tej zmiennej także.

W asemblerze tak nie ma. Sam zawsze decydujesz gdzie co umieścisz i uwierz mi że tak jest dobrze. Są bardzo często konkretne powody dla których chcesz by dana wartość była przechowywana w komórce 49152 a nie komórce 50000.

Realne programy na Zx Specrum mają przemieszane wartości - kod, dane, kod,dane,kod,dane. Ale się nie wywalają bo programista dba oto by każdy blok kody zakończyć przez RET albo instrukcję skoku i bajty danych które są potem nigdy nie zostaną osiągnięte przez wskaźnik aktualnie wykonywanej instrukcji.

[tdu]

Na dowód że dalej z pasmo walczę, kolejna wersja
mojego programiku.

Teraz muszę rozpracować kolizje z przeszkodami
i konieczna jest zmiana sposobu kasowania kropki
po przemieszczeniu, a to już wymaga operacji na bitach.

 

[trojacek]

Teraz muszę rozpracować kolizje z przeszkodami
i konieczna jest zmiana sposobu kasowania kropki
po przemieszczeniu, a to już wymaga operacji na bitach.

Nie śledzę co dokładnie robisz w assemblerze, ale jak chcesz "zmazać" uprzednio zapalony piksel, to po prostu przechowuj adres ekranu + bajt danych spod tego adresu (który był przed postawieniem punktu). Oszczędzisz od groma czasu procesora

[tdu]

W tym kierunku w zasadzie zmierzam.
Do tej pory kasowałem cały bajt.
Przy zbliżaniu kropki do krawędzi ekranu to się sprawdzało,
przy dowolnych przeszkodach, jest gorzej.
A teraz muszę opanować operację na bitach.

Aż się prosi żeby jeden piksel obrazu to był jeden bajt, o ile życie byłoby prostsze.

[trojacek]

Aż się prosi żeby jeden piksel obrazu to był jeden bajt, o ile życie byłoby prostsze.

I o ile "kolorowsze"

[pear]

Jest takie rozwiązanie, ale rozdzielczość spada do 32x24 "piksele"

[trojacek]

Alternatywnie - emulator Speccy256, choć nie do końca tam o to chodzi

[RafalM]

Aż się prosi żeby jeden piksel obrazu to był jeden bajt, o ile życie byłoby prostsze.

Rozumiem że to taki żart

Bo w takiej sytuacji pamięć ekranu przy tej samej rozdzielczości zajmowałaby 48kB a narysowanie czegokolwiek trwałoby 8 razy dłużej.

Oczywiście ludzie już kilka lat po Spectum stworzyli maszyny zdolne to pociągnąć ale Spectruma taki ciężar by całkowicie przygniótł.

[trojacek]

Bo w takiej sytuacji pamięć ekranu przy tej samej rozdzielczości zajmowałaby 48kB

Zgoda!

a narysowanie czegokolwiek trwałoby 8 razy dłużej.

Niekoniecznie. Po co wymyślono bitplany?

[matofesi]

a narysowanie czegokolwiek trwałoby 8 razy dłużej.

Niekoniecznie. Po co wymyślono bitplany?

Tylko bitplane'y powodują, że wracamy do organizacji w której jeden pixel nie jest jednym bajtem