IMHO nazwy mogą zostać, tylko podnieść progi, bo niedługo wszyscy będą królami offtopiku.

Nie tylko dużo bardziej optymalne, ale znaczy też coś innego, tj. to co "bp % 256".
Jednak przy zapisie do typu "char" żadne z nich nie jest potrzebne, bo i tak zostanie zapisane tylko najmłodsze 8 bitów. Można natomiast dać "(char) bp", aby uniknąć ewentualnych ostrzeżeń kompilatora.

Można się obejść bez stosu - przy przesuwaniu "i" omijać pary "[ ]". Jednak ze stosem powinno działać szybciej.

Ze stosem 6502? Nic się nie dzieje, co by się miało dziać?

Przecież jest wstrzymany?

Wystarczy:

 opt p+

i asembler już sam zoptymalizuje kod, skracając go dwukrotnie.

Wracając do tematu: Desert Dream jest też moim ulubionym demem. :)

Oto struktura bazy, którą obmyśliliśmy z Eru:

PK - primary key

Person - ludzie

    * PK: ID
    * FirstName
    * LastName
    * Nick
    * Country
    * PouetID
    * AtarikiID

AltNick - alternatywne nicki

    * PK: Person.ID, Nick

Group - grupy

    * PK: ID
    * Name
    * Abbreviation - np. TQA, SLT
    * PouetID
    * AtarikiID
    * Website

MemberOf - odwzorowanie kto był kiedy członkiem jakiej grupy

    * PK: Group.ID, Person.ID
    * FirstYear
    * LastYear

Product - wiadomo

    * PK: ID
    * Name
    * Year
    * ProductType.ID
    * PouetID
    * AtarikiID
    * Party.ID
    * Place
    * Website
    * RAM
    * Stereo
    * SIO - czy wymagana szeregowa stacja
    * Interlace - czy włączyć Flicker Fixer w emulatorze

ProductFile - pliki powiązane z produktem

    * PK: ID
    * ProductFileType.ID
    * Path
    * Ord (kolejność pokazywania)
    * Description (np. party  version, 1-disk, 2-disk itp)
    * Size

ProductOfGroup - jaka grupa stworzyła jaki produkt

    * PK: Product.ID, Group.ID

PersonRoleInProduct - w jakich rolach dana osoba brała udział w produkcie

    * PK: Product.ID, Person.ID, Nick, PersonRole.ID

ProductType - typy produkcji (demo, 1k, itp)

    * PK: ID
    * Name

PersonRole - rodzaje funkcji osoba może pełnić (grafika, muza, kod itp)

    * PK: ID
    * Name

ProductFileType - czy to XEX, CIN, PNG itp

    * PK: ID
    * Name

Party - np. Quast

    * PK: ID
    * Name

PartyEdition - np Quast 95 i Quast 96

    * PK: Party.ID, Year
    * City
    * Country

PartyReport - relacja z party

    * PK: ID
    * Party.ID
    * Year
    * Person.ID
    * URL - dla WWW
    * Product.ID - dla zinów itp.

E no, ta pętla ma 11 cykli, więc nijak nie mówi o tym, kiedy zmienił się VCOUNT. W zależności od tego jak wypadnie, zmieniona wartość VCOUNT może być przepisana do COLBAK 4 cykle później, albo 14 cykli później (plus oczywiście wartości pośrednie). I piszę tu o cyklach 6502, czyli rzeczywistych cykli może być więcej, w zależności od DL i pobierania PMG przez Antic.
Jeśli chcesz mieć stabilną tęczę, w której nie widać zmian koloru w środku linii, to użyj:

loop sta wsync
 lda vcount
 sta colbak
 jmp loop

Użycie sta colbak bezpośrednio po sta wsync może spowodować, że na TV z szeroką ramką będzie widać zmianę na prawej ramce (na większości TV i monitorów nie będzie różnicy).

VCOUNT zmienia się w trakcie wygaszenia poziomego. LMS nie wpływa na moment zmiany VCOUNT tylko powoduje, że Antic zjada dwa cykle 6502. Te cykle są zjadane parę cykli po zmianie VCOUNT.

:)

use LWP::UserAgent;
$a = LWP::UserAgent->new(agent => 'Mozilla/42.0 (Atari 800XL)');
$n = shift || 1;
%f = (xx_sondaz => 87310, s_wynik => 1, odpowiedz => 0, 'glosuj.x' => 8, 'glosuj.y' => 8);
while ($n--) {
    $r = $a->post('http://gospodarka.gazeta.pl/technologie/1,82008,4763595.html', \%f);
    print join(' ', $r->content =~ /Commodore 64 \(\d+\)|Atari \(\d+\)/g), "\n";
}

Zapisujemy np. do ankieta.pl i odpalamy podając ilość naszych głosów, np.

perl ankieta.pl 64