ZX Spectrum

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.

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.

Reply to
heby
Loading thread data ...

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.

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.

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.

Reply to
heby

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

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

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

Reply to
radekp

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

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.

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

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.

Reply to
heby

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.

Reply to
Silver Dream !

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

Ale tutaj oszczędności nie były potrzebne, bo i tak w przypadku gier w końcu trzeba było uruchomić tryb graficzny.

Nie trzeba było uruchamiać kodu, wystarczyło przy ładowaniu wpisać się w odpowiednie komórki.

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

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

Reply to
radekp

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

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

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.

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.

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.
Reply to
heby

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.

Reply to
Silver Dream !

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

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.

A to pamiętam.

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

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.

Reply to
radekp

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

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

Pozdrawiam

Reply to
RadoslawF

Nie rozszerzeń. Pamięc pod ROMem, była dostępna dla programów, ale wtedy nie działały procedury ROM. Albo musiałeś zrelokować dane z RAM do "pod ROM" w czasie ładowania swoim kodem albo nie mogłeś nic tam załadować w normalnym loaderze nic w ten obszar, bo procedury czytania były w ROM.

Z innych zastosowań: osobiście np. modyfikowałem character rom w ten sposób że go relokowałem gdzieś w ram, dodawałem ogonki, i po max 2 blokach (jak pamiętam) mogłem wyświetlać ekran tytułowy z pl znaczkami, bez ładowania całej czcionki od nowa. Załatwiała to garść instrukcji asm.

Wiele kopiarek do wersji magnetofonowych miało wydłużanie przerwy na żądanie przytrzymaniem klawisza (najczęsciej Select) w trakcie zapisu. Odpalanie kodu, bywało, zajmowało więcej czasu niż przerwa między blokami. W przypadku dysku nie miało to znaczenia...

Reply to
heby

Gre mozna bylo wgrac z dyskietki albo tasmy i zapisac na chwile do finala z tego co pamietam. To bylo w 1987-88 bylem wtedy maly dzieckiem, musialbym poszukac dokladnie.

Reply to
K

W dniu 2020-10-19 o 10:39, K pisze:

Nie szukaj. Freezowałeś kompa, zgrywałeś pamięć i potem mogłeś tę zgraną i zapisaną uruchomić. Ale uruchamianiem z carta bym tego nie nazwał. Tym bardziej że zapisywało się na dyskietce lub kasecie a nie na carcie.

formatting link

Pozdrawiam

Reply to
RadoslawF

dochodzi jeszcze do tego błąd w procedurze odczytu z magnetofonu, odkryty "niedawno"

formatting link
c.

Reply to
Cezar

Rozjadz musiałby być spory. Zdecydowanie najwiecej problemów było po stronie trzasków niż "wobble".

Owszem, dowód na to że CPU miał znacznie wiecej mocy obliczeniowej niż czytanie standardowej prędkości. Skoro potrafili to przyśpieszyć, dodatkowo warto pamiętać że standardowy odczyt z magnetofonu był częsciowo wspomagany sprzętowo.

Dalej, systemy turbo nie widziały problemy w przyśpieszaniu, wielokrotnie, prędkości odczytu, w dodatku przerzucając całośc roboty na cpu.

6502 to nie jest taki znowu powolny cpu, namiastkę 16 bitów miałeś w postaci strony zerowej.

Trudno powiedzieć, nie znam systemu zapisu spectrum, ale oryginalny atarowki polegał na detekcji częstotliwości, a systemy turbo to jednak czasy odstępu między zboczami.

Na jakies 30 osób które znałem w końcówce lat 80 na "osiedlu" z Atari XL/XE nie było ani jednej stacji.

To mniej więcej odwrotność statsytyki z USA gdzie magnetofony z Atari znikneły prawie od razu jak tylko się pojawiły i mało kto w ogóle widział je na oczy.

Reply to
heby

Nie znam ani jednej gry chodzącej w domyslnym trybie gr0. A nawet jesli były jakies pojedyncze, to i tak często ekran musiałbyś przeorganizowany z powodu scrolla, innej szerokości, przerwań rastrowych itd itp.

Reply to
heby

Pamiętam, że kiedy Rozgłośnia Harcerska w audycji "Radiokomputer" emitowała programy na różne ośmiobitowce, to ze Spectrum ciągle kombinowali z jakimiś interfejsami i zmieniali poziom emisji. Programy na Atari wchodziły za to bez problemu, sam kilka nagrałem.

Reply to
Artur Stachura

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.