Seban: +garść odnośników

2022-07-28T07:54:40Z

+garść odnośników

← poprzednia wersja		Wersja z 28 lip 2022, 09:54
Linia 3:		Linia 3:
	== Technikalia ==		== Technikalia ==

	System posiadał również swój format zapisu danych i obsługujący ten format loader. Loader systemu UM potrafił ładować [[Binarny_plik_DOS-u\|binarne pliki w formacie DOS]], jednak plik poddawany konwersji na ten format danych musiał zawierać segment RUN który jednoznacznie wskazywał miejsce uruchomienia wczytanego pliku. Dane poszczególnych segmentów wchodzących w skład pliku były ładowane jako jeden ciągły blok danych, oczywiście wczytywany plik mógł zawierać segmenty INIT, które były uruchamiane podczas wczytywania, jednak po takim segmencie generowany nowy segment danych.		System posiadał również swój format zapisu danych i obsługujący ten format [[loader]]. Loader systemu UM potrafił ładować [[Binarny_plik_DOS-u\|binarne pliki w formacie DOS]], jednak plik poddawany konwersji na ten format danych musiał zawierać segment RUN który jednoznacznie wskazywał miejsce uruchomienia wczytanego pliku. Dane poszczególnych segmentów wchodzących w skład pliku były ładowane jako jeden ciągły blok danych, oczywiście wczytywany plik mógł zawierać segmenty INIT, które były uruchamiane podczas wczytywania, jednak po takim segmencie generowany nowy segment danych.

	Suma kontrolna poszczególnych bloków była liczona poprzez wykonanie operacji logicznej [https://pl.wikipedia.org/wiki/Alternatywa_roz%C5%82%C4%85czna EOR] na wszystkich bajtach bloku, co było dość nieszczęśliwym pomysłem, bowiem skuteczność wykrywania przekłamań danych (szczególnie przy blokach o dużej długości) jest niewielka. Można przypuszczać iż takie sprawdzanie poprawności odczytanych danych było wybrane celowo, aby szansa wczytania nawet przekłamanych danych była większa, istniała przecież szansa że przekłamania nastąpią w mało wrażliwych miejscach programu (np. przekłamane zostaną dane reprezentujące grafikę). Użytkownik żył zatem w przekonaniu iż wszystko zostało wczytane poprawnie, mimo przekłamań które mogły nastąpić podczas niepoprawnego wczytania programu. Oczywiście autorzy rozwiązania mogli wybrać inny sposób liczenia sumy kontrolnej (np. używając chociażby sumy modulo 256, której obliczanie nie byłoby znacząco wolniejsze) jednak z jakiegoś powodu wybrane zostało właśnie rozwiązanie bazujące na EOR (być może ~~własnie~~ dlatego że takie rozwiązanie było stosowane również w przypadku AST).		Suma kontrolna poszczególnych bloków była liczona poprzez wykonanie operacji logicznej [https://pl.wikipedia.org/wiki/Alternatywa_roz%C5%82%C4%85czna EOR] na wszystkich bajtach bloku, co było dość nieszczęśliwym pomysłem, bowiem skuteczność wykrywania przekłamań danych (szczególnie przy blokach o dużej długości) jest niewielka. Można przypuszczać iż takie sprawdzanie poprawności odczytanych danych było wybrane celowo, aby szansa wczytania nawet przekłamanych danych była większa, istniała przecież szansa że przekłamania nastąpią w mało wrażliwych miejscach programu (np. przekłamane zostaną dane reprezentujące grafikę). Użytkownik żył zatem w przekonaniu iż wszystko zostało wczytane poprawnie, mimo przekłamań które mogły nastąpić podczas niepoprawnego wczytania programu. Oczywiście autorzy rozwiązania mogli wybrać inny sposób liczenia sumy kontrolnej (np. używając chociażby sumy modulo 256, której obliczanie nie byłoby znacząco wolniejsze) jednak z jakiegoś powodu wybrane zostało właśnie rozwiązanie bazujące na EOR (być może właśnie dlatego że takie rozwiązanie było stosowane również w przypadku AST).

			== Odnośniki zewnętrzne ==

			*[http://www.atari.org.pl/forum/viewtopic.php?pid=297682#p297682 opis i schemat interfejsu] w wersji "standardowej" napotkanego w magnetofonie [[Piguła\|Piguły]].
			*[http://www.atari.org.pl/forum/viewtopic.php?pid=280066#p280066 opis i schemat interfejsu] w wersji "rozszerzonej" (UMex) napotkanego w magnetofonie z kolekcji [[Uicr0Bee]]
			*[http://www.atari.org.pl/forum/viewtopic.php?id=5802 opis, schemat i "zrzut" "Super Cartridge"] zawierający oprogramowanie systemowe dołączane przez firmę [[Unerring Masters]] do systemu.
			*[http://www.atari.org.pl/forum/viewtopic.php?pid=246901#p246901 opis, schemat i "zrzut" kartridża] zawierającego oprogramowanie dla systemów AST/ATT/UM dystrybuowanego przez firmę [[Atrax]].

	==Zobacz też==		==Zobacz też==

Seban: początkowe informacje o systemie

2022-07-18T13:13:37Z

początkowe informacje o systemie

Nowa strona

System turbo turbo przeznaczony dla magnetofonów "firmowych" Atari, opracowany i montowany przez firmę [[Unerring Masters]] z Łodzi, popularny i szeroko rozpowszechniony w tymże regionie. Jak wiele systemów turbo przeznaczonych dla magnetofonów, system bazował na modulacji szerokości impulsu (tzw. [https://pl.wikipedia.org/wiki/Modulacja_szeroko%C5%9Bci_impuls%C3%B3w PWM]). Format zapisu danych (długości impulsów kodujących poszczególne stany) inspirowany był na [[Atari Super Turbo]] (AST) i pomimo odmiennej konstrukcji sprzętowej płytki interfejsu bez problemów można używać z narzędziami i programami przeznaczonymi dla systemów AST oraz [[Atari Turbo Tape]] (ATT). Nawet sam producent dostarczał [[Cartridge]] z oprogramowaniem zawierającym loadery dla systemów AST i ATT.

== Technikalia ==

System posiadał również swój format zapisu danych i obsługujący ten format loader. Loader systemu UM potrafił ładować [[Binarny_plik_DOS-u|binarne pliki w formacie DOS]], jednak plik poddawany konwersji na ten format danych musiał zawierać segment RUN który jednoznacznie wskazywał miejsce uruchomienia wczytanego pliku. Dane poszczególnych segmentów wchodzących w skład pliku były ładowane jako jeden ciągły blok danych, oczywiście wczytywany plik mógł zawierać segmenty INIT, które były uruchamiane podczas wczytywania, jednak po takim segmencie generowany nowy segment danych.

Suma kontrolna poszczególnych bloków była liczona poprzez wykonanie operacji logicznej [https://pl.wikipedia.org/wiki/Alternatywa_roz%C5%82%C4%85czna EOR] na wszystkich bajtach bloku, co było dość nieszczęśliwym pomysłem, bowiem skuteczność wykrywania przekłamań danych (szczególnie przy blokach o dużej długości) jest niewielka. Można przypuszczać iż takie sprawdzanie poprawności odczytanych danych było wybrane celowo, aby szansa wczytania nawet przekłamanych danych była większa, istniała przecież szansa że przekłamania nastąpią w mało wrażliwych miejscach programu (np. przekłamane zostaną dane reprezentujące grafikę). Użytkownik żył zatem w przekonaniu iż wszystko zostało wczytane poprawnie, mimo przekłamań które mogły nastąpić podczas niepoprawnego wczytania programu. Oczywiście autorzy rozwiązania mogli wybrać inny sposób liczenia sumy kontrolnej (np. używając chociażby sumy modulo 256, której obliczanie nie byłoby znacząco wolniejsze) jednak z jakiegoś powodu wybrane zostało właśnie rozwiązanie bazujące na EOR (być może własnie dlatego że takie rozwiązanie było stosowane również w przypadku AST).

==Zobacz też==
*[[Systemy turbo]]

[[Kategoria:Atari 8-bit]]
[[Kategoria:Magnetofonowe systemy turbo]]

{{stub}}

UM Turbo - Historia wersji

Seban: +garść odnośników

Seban: początkowe informacje o systemie