UM Turbo

From Atariki

(Różnice między wersjami)
Jump to: navigation, search
Wersja z dnia 13:13, 18 lip 2022
Seban (Dyskusja | wkład)
(początkowe informacje o systemie)
← Previous diff
Aktualna wersja
Seban (Dyskusja | wkład)
(+garść odnośników)
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ż==

Aktualna wersja

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

Zobacz też


Ten artykuł to tylko zalążek. Możesz pomóc rozwojowi Atariki poprzez rozszerzenie go o więcej informacji.

Personal tools