-
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.
Następne wpisy z tego wątku
- 18.10.20 12:25 Silver Dream !
- 18.10.20 13:39 r...@k...pl
- 18.10.20 20:18 RadoslawF
- 18.10.20 20:31 heby
- 19.10.20 10:39 K
- 19.10.20 13:36 RadoslawF
- 19.10.20 15:13 J.F.
- 19.10.20 15:19 J.F.
- 19.10.20 15:22 J.F.
- 19.10.20 15:54 Cezar
- 19.10.20 18:44 heby
- 19.10.20 18:56 heby
- 19.10.20 20:19 Artur Stachura
- 20.10.20 01:14 Silver Dream !
- 20.10.20 14:46 RadoslawF
Najnowsze wątki z tej grupy
- System operacyjny dla 6800?
- Przyłączenie działki do sieci elektrycznej
- Działalność nierejestrowana/definicja sprzętu elektronicznego/misie i kolejki
- Smukły, długi ściągacz izolacji do kynaru
- rezystor 3 omy 400W
- [newbie] Jaki multimetr za 2-4 stówy?
- szafka sieciowa
- Raspberry Pi 5 + dyski SATA
- lutownica na węgiel
- Znów czary (albo niewiedza) - tym razem fotowoltaika
- Chess
- Vitruvian Man - parts 7-11a
- przeźroczyste koszulki
- Re: Win 10/11 nie lubi OKI
- Programator czasowy TUYA.
Najnowsze wątki
- 2024-05-18 Warszawa => Mid PHP Developer (Laravel) <=
- 2024-05-18 Warszawa => Software .Net Developer <=
- 2024-05-18 Warszawa => Mid/Senior QA Engineer <=
- 2024-05-18 Ulm => Solution Architect (sichere Kommunikation und IoT-Loesungen <=
- 2024-05-18 Katowice => Head of Virtualization Platform Management and Operating S
- 2024-05-18 Warszawa => SAP WM Consultant / Execution <=
- 2024-05-18 Wrocław => Consultant/Implementer Comarch ERP XL <=
- 2024-05-18 Gdańsk => Head of International Freight Forwarding Department <=
- 2024-05-18 Warszawa => Account Manager (Recruitment Services) <=
- 2024-05-18 Łódź => Salesperson - CRM Systems <=
- 2024-05-18 Łódź => Handlowiec - Systemy CRM <=
- 2024-05-17 ZŁOMNIK o pracy w TVN TURBO, nowych przepisach i współczesnej motoryzacji. Turbo Taryfa!
- 2024-05-17 Białystok => DevOps Engineer Conexa First (Contractor) <=
- 2024-05-17 Warszawa => Starszy inżynier oprogramowania (Rust) <=
- 2024-05-17 Zabrze => Junior HelpDesk <=