-
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
- pradnica krokowa
- Nieustający podziw...
- Coś dusi.
- akumulator napięcie 12.0v
- Podłączenie DMA 8257 do 8085
- pozew za naprawę sprzętu na youtube
- gasik
- Zbieranie danych przez www
- reverse engineering i dodawanie elementów do istniejących zamkniętych produktów- legalne?
- Problem z odczytem karty CF
- 74F vs 74HCT
- Newag ciąg dalszy
- Digikey, SN74CBT3253CD, FST3253, ktoś ma?
- Szukam: czujnik ruchu z możliwością zaączenia na stałe
- kabelek - kynar ?
Najnowsze wątki
- 2025-01-19 Test - nie czytać
- 2025-01-19 qqqq
- 2025-01-19 Tauron przysyła aneks
- 2025-01-19 Nowa ładowarka Moya a Twizy -)
- 2025-01-18 Power BANK z ładowaniem przelotowym robi PRZERWY
- 2025-01-18 Pomoc dla Filipa ;)
- 2025-01-18 znowu kradno i sie nie dzielo
- 2025-01-18 Zieloni oszuchiści
- 2025-01-18 Zielonka => Specjalista ds. public relations <=
- 2025-01-18 Warszawa => Frontend Developer (JS, React) <=
- 2025-01-18 Warszawa => Software .Net Developer <=
- 2025-01-18 Warszawa => Developer .NET (mid) <=
- 2025-01-18 Katowice => Administrator IT - Systemy Operacyjne i Wirtualizacja <=
- 2025-01-17 Zniknął list gończy za "Frogiem". Frog się nam odnalazł?
- 2025-01-17 Kto wytłumaczy "głupiemu" prezydentowi Dudzie wielką moc prawną "dekretu premiera" TUSKA? [(C)Korneluk (2025)]