On 16/10/2020 22:30, r...@k...pl wrote:
> Nawet nie pamiętam co oryginalne Atari potrafiło podczas ładowania

Wszystko, Po każdym bloku miałeś możliwośc odpalenia kodu który się
własnie załadował. Dowolną ilość razy w trakcie ładowania.

>, ale aby
> wyświetlać wystarczyło nagrać pamięć ekranu.

To nie jest takie oczywiste w Atari. Ogólnie aby coś wyświetlić programy
uruchamiały kod który sobie wyswietlał, co mu pasowało.

W Atari nie ma czegoś takiego jak "pamięc ekranu". Do jest mocno
dynamiczne pojęcie bo możesz wyśwetlić dowolny fragment RAM (i ROM) w
dowolny sposób jaki skonfigurujesz w ANTICu, większośc loaderów duzych
girr właśnie po to zmieniała wygląd ekranu aby wyświetlać coś innego niż
domyslną lokalizację RAM, potrzebną im do czegoś innego.

do góry

On 16/10/2020 20:04, J.F. wrote:
> Tam jeszcze bylo tak, ze na poczatku bloku procek mierzyl predkosc.
> Jesli magnetofon nie byl zbyt stabilny, to moglby byc problem na
> dluzszych blokach.

Zazwyczaj kaseta nie spowalniała jak już została raz policzona na
rozbiegówce. A jesli spowalniała to była na tyle kiepska że żadna
technologia by nie pomogła.

> No i .. na 6502 to dluzszy blok bylby problemem z uwagi na 8-bitowe
> rejestry, lepsze male.

Procesor ogólnie dużo nie robił podczas odczytu, czego dowodem są
systemy takie jak blizzard które potrafiły czytać wielokrotnie szybciej
(małą przeróbką magnetofonu). CPU nie był ograniczeniem, ograniczeniem
była technologia zapisu na taśmie i kiepskiej jakości kod w systemie.
Systemy Turbo do Atari były znakomite jesli chodzi o jakość zapisu,
wieloktornie lepsze niż oryginalny powolny tryb magnetofonu.

> Procedura w ROM chyba nie potrafila dluzszych.

Pierwsze dwa "normalne" bloki zawierały nową procedurę.

Oczywiście tego typu zabay były w mniejszości. W latach 80/90 rządził
"wykrzyknik", czyli loader wyświetlający mały znak "!" na ekranie w
procesie ładowania, który nie dośc że był absurdalnie długi to jeszcze
nie miał żadnych zalet. Ale był niesamowicie popularnym loaderem.

do góry

Sat, 17 Oct 2020 17:53:41 +0200, w <rmf427$9dt$1@dont-email.me>, heby
<h...@p...onet.pl> napisał(-a):

> On 16/10/2020 22:30, r...@k...pl wrote:
> > Nawet nie pamiętam co oryginalne Atari potrafiło podczas ładowania
>
> Wszystko, Po każdym bloku miałeś możliwośc odpalenia kodu który się
> własnie załadował. Dowolną ilość razy w trakcie ładowania.
>
> >, ale aby
> > wyświetlać wystarczyło nagrać pamięć ekranu.
>
> To nie jest takie oczywiste w Atari. Ogólnie aby coś wyświetlić programy
> uruchamiały kod który sobie wyswietlał, co mu pasowało.

Ale to pamiętam, że było możliwe -- wystarczyło pisać do pamięci ekranu.
Albo chyba profesjonalnie było umieścić gdzieś w pamięci nowy ekran, a potem
tylko (z poziomu ładowania) umieścić wskazanie do nowego ekranu.

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 :)

> W Atari nie ma czegoś takiego jak "pamięc ekranu". Do jest mocno
> dynamiczne pojęcie bo możesz wyśwetlić dowolny fragment RAM (i ROM) w
> dowolny sposób jaki skonfigurujesz w ANTICu, większośc loaderów duzych
> girr właśnie po to zmieniała wygląd ekranu aby wyświetlać coś innego niż
> domyslną lokalizację RAM, potrzebną im do czegoś innego.

Coś mi tam właśnie zaświtało, że były dwie komórki, które wskazywały gdzie w
pamięci jest ten nowy ekran.
Ale, żeby go pokazać, nie musiano nic uruchamiać.

do góry

On 17/10/2020 20:31, r...@k...pl wrote:
>> To nie jest takie oczywiste w Atari. Ogólnie aby coś wyświetlić programy
>> uruchamiały kod który sobie wyswietlał, co mu pasowało.
> Ale to pamiętam, że było możliwe -- wystarczyło pisać do pamięci ekranu.

Można pisać gdzie się chce podczas czytania, w tym i w domyslny RAM
trybu gr0.

> Albo chyba profesjonalnie było umieścić gdzieś w pamięci nowy ekran, a potem
> tylko (z poziomu ładowania) umieścić wskazanie do nowego ekranu.

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.

> 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.

> Coś mi tam właśnie zaświtało, że były dwie komórki, które wskazywały gdzie w
> pamięci jest ten nowy ekran.

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.

> Ale, żeby go pokazać, nie musiano nic uruchamiać.

Aby pokazać coś innego niż ekran domyślny podczas ładowania wymagane
było uruchomienie kodu.

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.

do góry

On 16/10/2020 14:38, Cezar wrote:

> zgadza sie- ok 1500b/s co bylo dość szybkim transferem jak na owe czasy.
> w atari to bylog 600b/s a w commodore chyba jeszcze mniej ale w
> commodore można było programowo to zwiększyć bo dekodowanie FSK było
> programowe.

W Commodore to nie było FSK i wymagało sprzętowego wsparcia. Niemniej
parametry czasowe można było modyfikować w bardzo szerokim zakresie
wyłącznie programowo, dzięki czemu tzw. ,,turbo" (takie czy inne) nie
wymagało zmian w napędzie/sprzęgu napędu kaset.

do góry

Sat, 17 Oct 2020 21:48:58 +0200, w <rmfhrb$dop$1@dont-email.me>, heby
<h...@p...onet.pl> napisał(-a):

> On 17/10/2020 20:31, r...@k...pl wrote:
> > Albo chyba profesjonalnie było umieścić gdzieś w pamięci nowy ekran, a potem
> > tylko (z poziomu ładowania) umieścić wskazanie do nowego ekranu.
>
> 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.

> > 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.

> > Coś mi tam właśnie zaświtało, że były dwie komórki, które wskazywały gdzie w
> > pamięci jest ten nowy ekran.
>
> 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, żeby go pokazać, nie musiano nic uruchamiać.
>
> Aby pokazać coś innego niż ekran domyślny podczas ładowania wymagane
> było uruchomienie kodu.
>
> 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ć.

do góry

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.

do góry

On 18/10/2020 10:44, heby wrote:

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

Tak, bo to tak samo dobra pamięć jak każda a wiadomo, że domyślnie nie
wykorzystywana na kod. Tyle, że rzadko kiedy ktoś się postarał aby
uczynić ten kod niewidocznym i stąd te ,,kaszany" na ekranie przed
uruchomieniem.

do góry

Sun, 18 Oct 2020 10:44:18 +0200, w <rmgv93$sji$1@dont-email.me>, heby
<h...@p...onet.pl> napisał(-a):

> > 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.

W czym problem?
Ładowałeś najpierw do RAM ekran, a potem wpisując się w komórki (podczas
ładowania) przełączałeś się na ten nowy ekra.

> 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.

A to pamiętam.

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

A tu pamiętam, że były gry korzystające z rozszerzeń RAM-u, ale chyba za wiele
ich nie było.

> 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.

A to akurat był świetny pomysł, bo oszczędzało czas ładowania.
Szczególnie przydatne przy freezerze, gdy zrzut pamięci był dokonany z regułami
sztuki (czyli restart kompa i wyczyszczenia RAM) przed ładowaniem
zabezpieczonej gry.

do góry

W dniu 2020-10-18 o 12:25, Silver Dream ! pisze:

>> [1] Za to na C64 powszechne było wciskanie decrunchera w pamiec ekranu.
>
> Tak, bo to tak samo dobra pamięć jak każda a wiadomo, że domyślnie nie
> wykorzystywana na kod. Tyle, że rzadko kiedy ktoś się postarał aby
> uczynić ten kod niewidocznym i stąd te ,,kaszany" na ekranie przed
> uruchomieniem.

A po co robić go niewidzialnym?
Użytkownik widzi że program działa i nie zastanawia się czy
aby komputer nie wisi.


Pozdrawiam

do góry