eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaZX Spectrum › Re: ZX Spectrum
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!3.eu.feeder.erj
    e.net!feeder.erje.net!eternal-september.org!feeder.eternal-september.org!reader
    02.eternal-september.org!.POSTED!not-for-mail
    From: heby <h...@p...onet.pl>
    Newsgroups: pl.misc.elektronika
    Subject: Re: ZX Spectrum
    Date: Sun, 18 Oct 2020 10:44:18 +0200
    Organization: A noiseless patient Spider
    Lines: 61
    Message-ID: <rmgv93$sji$1@dont-email.me>
    References: <6...@g...com>
    <5f897e17$0$31099$65785112@news.neostrada.pl>
    <rmc47k$bk4$1$cezar91@news.chmurka.net>
    <s...@l...localdomain> <rmcjom$a5j$1@dont-email.me>
    <q...@4...com> <rmf427$9dt$1@dont-email.me>
    <t...@4...com> <rmfhrb$dop$1@dont-email.me>
    <i...@4...com>
    Mime-Version: 1.0
    Content-Type: text/plain; charset=iso-8859-2; format=flowed
    Content-Transfer-Encoding: 8bit
    Injection-Date: Sun, 18 Oct 2020 08:44:20 -0000 (UTC)
    Injection-Info: reader02.eternal-september.org;
    posting-host="73ffa026c8ed801f9d015ef52c6bf23d";
    logging-data="29298";
    mail-complaints-to="a...@e...org";
    posting-account="U2FsdGVkX19B4Vq+d+VjkwxapozOTvEB"
    User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
    Thunderbird/68.12.1
    Cancel-Lock: sha1:ZsSE0jDC/ypmp6bW6JwIZy/Zubs=
    In-Reply-To: <i...@4...com>
    Content-Language: en-US
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:758014
    [ ukryj nagłówki ]

    On 18/10/2020 01:57, r...@k...pl wrote:
    >> Nie, to często jedyne wyjście aby mieć więcej pamieci. Ekran Atari mógł
    >> zając kilkadziesiąt bajtów z prostym napisem i to była *oszczędnośc* w
    >> stosunku do podstawowego trybu graficznego.
    > Ale tutaj oszczędności nie były potrzebne, bo i tak w przypadku gier w końcu
    > trzeba było uruchomić tryb graficzny.

    Nigdy taki, jaki miał system operacyjny w trybie BASICa czy DOSa.

    Nie pamiętam ani jednej poważnej gry pracujące w trybie gr0.

    >>> I ponieważ nie zawsze system od razu przełączał się na nowy ekran, to czasem
    >>> ten nowy ekran pokazywał się z opóźnieniem -- za każdym ładowaniem w innym
    >>> momencie :)
    >> Zasze przełączanie było natychmitowe, kod się wywoływał, tworzył display
    >> list, i ramkę pźniej było go widać na ekranie. Nie spotkałem gry na
    >> Atari która robiła by machloje z ekranem w sposób randomiczny.
    > Nie trzeba było uruchamiać kodu, wystarczyło przy ładowaniu wpisać się w
    > odpowiednie komórki.

    To powoduje że nie kontrolujesz gdzie jest ekran. To poważny problem
    podczas pisania własnych programów ponieważ w środku RAMu masz dziurę na
    bufor pamięci gfx.

    Co z resztą łatwo zauważyć: cześc gier bez podmiany bufora ekranu w
    trakcie ładowania niszczyła display list antica powodując chaos na
    ekranie do ukończenia ładowania.

    >> Nie, to jest nieskończenie bardziej skomplikowane. Na Atari nie ma
    >> czegoś takiego jak "ekran". Jest display list Antica który okresla jak
    >> dma ma pobierać i jak interpretować zawartośc RAM. To jest zdecydowanie
    >> wiecej pamieci niż 2 bajty, powiedzmy że minimum kilkadziesiąt aby
    >> wyświetlić jeden duży napis.
    > Jak przez mgłę pamiętam, że jednak adres RAM-u z tą "zawartością dla Antica"
    > wystarczyło wpisać w dwie komórki, aby Antic wiedział co ma wyświetlać.

    ALe najpierw należało stworzyć stosowne display list i zawartość RAM
    gdzieś na boku. W kilku sekcjach. To jest kilkadziesiąt bajtów co
    najmniej + overheat sekcji.

    >> Można oczywiście załadować jakiś napis wprost w domyślną lokalizację
    >> pamieci gr0, ale to jest jechanie po bandzie i nie kojarze ani jednej
    >> gry/programu robiącego coś tak niebezpiecznego.
    > To w ogóle nie było niebezpieczne, a oszczędzało uruchamianie zbędnego kodu.
    > Niestety, pamięć ulotna nie pozwala mi sobie przypomnieć jakie cuda można było
    > z tym zrobić.

    Mamy więc rózne doswiadczenia. Na kilkaset gier kaseta/dysk nie pamiętam
    ani jednej ładującej cokolwiek w pamięc zastanego ekranu [1]. Za to
    setki uruchamiające kod zestawiajacy antica albo przynajmniej tworzące
    display list używajac mechanizmu sekcji.

    Uruchamianie kodu było niezbędne również po to aby odzyskać RAM
    przykryty ROMem lub robić relokacje w czasie rzeczywistym.

    Jeden z kompresorów (kiepskich) po każdej sekcji zerował następny blok
    pamięci ponieważ jego działanie polegało na szatkowaniu pliku tak aoby
    ominąć framenty z zerami. Zerowanie odbywało się właśnie poprzez wołanie
    kawałka kodu robiącego to podczas ładowania, dziesiatki razy.

    [1] Za to na C64 powszechne było wciskanie decrunchera w pamiec ekranu.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: