Dyskusja:XL OS

From Atariki

Dyskusja przeniesiona ze strony Dyskusja_użytkownika:Krótki

Poprawiłeś numery wersji XL OS-u z np. BB 01.02 na BB000001 rev. 2. Zaczynam mieć wątpliwości, czy słusznie - np. w Atari ST wersja TOS-u jest zakodowana w BCD na 32 bitach, więc mamy np. (o ile dobrze pamiętam) $00000104, ale w literaturze ten TOS nazywa się "1.04", z pominięciem początkowych zer. Tu chyba należałoby ten kod rozumieć tak samo, ostatecznie jest to ta sama firma. Proponuję więc skrócić notację i zapisywać te numery jako np. "BB 1.02" (bo się rozumie samo przez się, że ostatnie cyfry to numer rewizji). KMK 12:11, 6 wrz 2010 (CEST)

Też się zastanawiam. Parę spostrzeżeń:

* Nie znam literatury dot. ST. Być może w literaturze jest napisane jak należy interpretować numer wersji - że bajt 3. to major number, że bajt 4. to minor number i żeby nie używać wiodących zer. Natomiast w XL Addendum wyraźnie napisali, że pełna forma "Part number" to AANNNNNN bez spacji, i nie znam innych dokumentów które odnoszą się do part number. W każdym razie jeśli mamy skracać konwencję, to usunąłbym spację pomiędzy "BB" a "1.02", a poza tym wypadałoby napisać w Sygnatura ROM, że stosujemy formę skróconą. Apropos - chyba ten artykuł powinien się nazywać Sygnatura XL OS.

* Wywalenie słowa rev. - czemu nie. Ale 0 sprzed numeru rewizji bym wywalił - ani w kodzie źródłowym ani w literaturze 0 przed numerem rewizji nie było stosowane.

* Według firmy Atari, najwyraźniej Part number w ogóle nie ma znaczenia przy rozpoznawaniu wersji systemu. W kodzie źródłowym piszą sobie "Revision 10 (1200XL), Revision 1 (600XL/800XL)". Założenie było takie, że numer rewizji wraz z modelem komputera wystarczają do określenia wersji systemu. W XL Addendum opisują że aby rozpoznać wersję systemu XL, należy sprawdzić "Option byte" ($FFF1, 1 dla 1200XL, 2 dla późniejszych (w tym 14050XLD)) i "Revision number". Może my też powinniśmy zacząć stosować parę Option byte.Revision number? (Tracimy w ten sposób możliwość odróżnienia ROMów do 65XE i 1450XLD, ale OS 1450XLD jest prototypem więc i tak przy dyskusji o nim trzeba podawać więcej informacji) (Druga komplikacja - w systemach dla 65816 z Option byte zrezygnowano.)

* Internet nie książka, nie musimy oszczędzać miejsca ;) --Krótki 12:54, 6 wrz 2010 (CEST)

ad 1: z literatury nt. ST nie pamiętam instrukcji interpretacji tego numeru. Niemniej z całą pewnością występuje on w takiej formie w różnych dokumentach autorstwa Atari, instrukcjach do sprzętu itede. więc raczej nie ma wątpliwości. Co do 8-bit, istotnie, ludzie posługują się raczej terminami typu "rev. 5", co a) mnie osobiście nic nie mówi, b) ma się nijak do numerków zapisanych w sygnaturze, c) jak sam zauważasz, ogranicza możliwość identyfikacji OS-u. A chyba po coś ten numer wersji tam jest - i identyfikuje rewizje OS-u skuteczniej niż cokolwiek innego, więc oparłbym się na tym. Za skróceniem konwencji przemawia też pewien wzgląd praktyczny: przeczytaj sobie na głos "BB000001 rev. 2". Spacja: dla mnie naturalne jest, że litery od cyfr się oddziela spacją, no ale to w sumie kwestia przyjętej konwencji (jak zdecydujemy, tak będzie).

ad 2: patrz konwencja ST - $00000104 niektórzy próbowali nazywać "TOS-em 1.4" (jeden-cztery) ale Atari rozwiało wątpliwości na ten temat wpuszczając po 1.06 TOS 1.62. Wniosek z tego chyba, że np. TOS Falcona to jest "cztery-zero-cztery" a nie "cztery-cztery", a XL OS jest "jeden-zero-dwa" a nie "jeden-dwa"...

ad 3: w ogóle w tym jest zamieszanie, po terminie "part number" oczekiwałoby się tam czegoś w rodzaju "C061598", a nie BB... Poza tym, jeśli bazować na konwencjach przyjętych dla ST, to mniejsza rewizja ROM-u v. BB 1.03 powinna się nazywać np. BB 1.39 a nie BB 1.59 (tak samo jak mniejsza rewizja TOS-u 1.06 nazywa się TOS 1.62). Option byte w drugim bloku miało pewnie w teorii "identyfikować produkt", i przedtramielowe Atari się pewnie tego trzymało - ale tramielowe już nie, XE mają ROM od 800XL, więc ten bajt tak naprawdę do niczego nie służy ($02 oznacza "może 800XL a może nie"). Z drugiej strony rev. no. bywa takie samo przy różnych numerach wersji, np. BB 2.03 i BB 1.03. Ja wiem, że ten pierwszy jest prototypowy, niemniej istnieje i dobrze byłoby, żeby system numeracji to uwzględniał.

Co do Sygnatura ROM vs Sygnatura XL OS - masz rację. KMK 13:27, 6 wrz 2010 (CEST)

Przestań porównywać Atari Corporation z Atari, Inc. Nie ma żadnych podstaw żeby przypuszczać, że te 2 różne firmy, w 2 różnych systemach komputerowych, planowały stosować jednolitą konwencję numerowania wersji. Argumenty z tego wynikające całkowicie pomijam.

ad.1. Ale ja nie mam nic przeciwko - tylko żeby wspomnieć o skróceniu w odpowiednim artykule. Moglibyśmy w ogóle używać tylko part numberu, gdyby nie to, że po przejęciu przez TTL najwyraźniej zapomnieli o zmianie tego pola przy każdej nower wersji systemu.

ad.2: Nie rozumiem jak fakt istnienia wersji 1.62 ma uniemożliwiać nazywanie poprzedniej wersji per 1.6. Przecież 62 > 6. Abstrahując: Atari, Inc. też rozwiewa wątpliwości - w kodzie źródłowym używali Revision <numer>" bez wiodącego 0 i nie ma powodu żeby to zmieniać.

ad.3: Sądzę że option byte miał identyfikować nie konkretny model (zauważ, w 600XL i 800XL, a także w planowanym 1450XLD, option byte wszędzie był 2) ale architekturę. Czyli: 1 = XL bez wbudowanego BASIC-a, 2 = XL z wbudowanym BASIC-em (1450XLD z punktu widzenia użytkownika to ta sama architektura, bo dodatkowe urządzenia są obsługiwane przez PBI, i nie wymagają specjalnego traktowania przez software). Idąc tym tropem, 65XE i 130XE to również architektura 2. Konwencja sypie się dopiero przy XEGS z wbudowaną grą i odłączaną klawiaturą. --Krótki 14:33, 6 wrz 2010 (CEST)

ad 1: moim zdaniem są podstawy. Po przejęciu przez Tramieli zmienił się właściciel i kierownictwo, ale reszta została taka sama - nowy właściciel przejął przedsiębiorstwo razem z jego wewnętrznymi procedurami i konwencjami, nie tracąc czasu na wymyślanie nowych ani importowanie ich z Commodore. Oto dowód i nie ma podstaw przypuszczać, że z numerami wersji było inaczej. Co więcej, sądzę, że numeracja wersji TOS-u ST jest (na tej właśnie zasadzie) inspirowana przez stary system przyjęty w Atari Inc. Więc porównania są zasadne.

ad 2: "1.62" to jest następna rewizja po "1.06" (zgodnie z przyjętą dla TOS-u 1.x konwencją, że parzyste numery są oficjalne, a nieparzyste to bety, rewizja TOS-u 1.06 nie mogła się nazywać "1.61"), i nie jest tak, żeby między '6' (czy też '06') a '62' istniało 28 rewizji. Tu się chyba zgadzamy? Teraz, "1.06" jest zakodowany jako $00000106, natomiast "1.62" jako $00000162 - wniosek z tego, że numer rewizji prezentuje dwie ostatnie cyfry samego siebie ("sześć" = 06, "sześć-dwa" = 62). Taka jest zresztą ostateczna wykładnia zaprezentowana przez Atari (mimo początkowych wahań). Przypuszczam, że zjawisko w rodzaju BB 1.03 ale BB 1.59 wskazuje na to samo (acz $03 we wcześniejszej rewizji a $3b w późniejszej to niezła zagwozdka, co w zasadzie autor miał na myśli). Zwracam uwagę, że to "1.59" jest już wymyślone przez Atari pod rządami Tramieli (to a propos analogii z ST).

ad numer rewizji w kodzie źródłowym: że niestety numery w kodzie źródłowym to nie są te same numery, jakie widnieją w sygnaturze. Dowód: OS oznaczony w źródle jako "rev. 5" ma CC 1.04 (!) w sygnaturze.

ad 3: no dobrze, ale dlaczego akurat BASIC? To co prawda niezły pomysł, ale czy tak miało być rzeczywiśćie? Równie dobrze option byte = $02 oznaczać może PBI (którego nie ma w 1200XL). Wtedy konwencja jest tak samo przestrzegana w Inc. i tak samo olewana w Corp. (bo np. 65XE ma $02 ale nie ma PBI, mimo że ma w ROM-ie procedury jego obsługi). Tak czy owak, dla nas nic mądrego z tego nie wynika (option = $02 - "może jest PBI", albo "jest BASIC, i może jeszcze coś, ale może nie"). KMK 15:35, 6 wrz 2010 (CEST)

ad.1: Czysta spekulacja. Niby czemu przejmowanie konwencji z Atari, Inc. (do której trzeba się najpierw dokopać, znaleźć ludzi którzy ją znają i nie zostali podczas przejęcia zwolnieni) ma być mniej czasochłonne niż wymyślenie w 5 minut, że "przeznaczamy 4 bajty na numer wersji w BCD"? Fakty zaś są takie: a) Nad TOSem pracowali inni ludzie, mogli robić co chcieli, b) system jakiego używali pracownicy działu, w którym katalogowano części ma się nijak do tego, co używały 2 osobne zespoły programistów, c) spekulujesz.

ad.2: No to skoro początkowo TOS się nazywał 1.2 i 1.4, i zakładając że taka konwencja była przeniesiona z Atari, Inc., to dochodzimy do wniosku, że jednak zera ma nie być?

ad. numer rewizji: We wszystkich poprzednich wydaniach OSu numer rewizji w kodzie źródłowym zgadzał się z kodem w sygnaturze. A rewizja 5 nie istnieje w postaci fizycznego ROMu i nie wiadomo nawet, czy ta wersja kodu źródłowego jest ostateczna, czy może ktoś przerwał jej pisanie w pół zdania. Co i tak nie zmienia faktu, że numer jest bez 0 wiodącego i jest to jedyny udokumentowany sposób zapisu numeru rewizji.

ad.3:Masz rację, można przyjąć że option byte=02 oznaczał obecność i BASIC-a i procedur PBI. Spójrz na to z punktu widzenia uruchamianego programu: Nawet jeśli 65XE nie ma wyjścia PBI, to program ma ostęp do funkcji PBI i może je wywoływać bez obawy, że skoczy w maliny. Zatem dodatkowa informacja o braku PBI nie jest w polu Option Byte potrzebna. (Ciekawostka: W źródle rev.5 Option Byte=2 występuje też w pierwszej sygnaturze ROM.) --Krótki 18:31, 6 wrz 2010 (CEST)

ad 1: istotnie, spekulacja. Tylko że ty nie masz do jej zbicia nic więcej. Faktem jest, że nad TOS-em pracowali nowi ludzie. Spekulacją jest, że mogli robić co chcieli. A nawet jeśliby mogli, to z tego nie wynika w żaden sposób, że rzeczywiście wymyślili sobie ten system numeracji wersji z niczego, a nie oparli się na istniejących w firmie procedurach nadawania firmware'owi numerów wersji.

ad 2: albo że zero ma być, skoro Atari się na to zdecydowało w przypadku TOS-u (a w 8-bit ciągnęli ewidentnie bardzo podobny, o ile nie ten sam, system numeracji). Poza tym argument praktyczny: 1.02 w zestawieniu z 1.59 nawet wygląda bardziej konsekwentnie (zawsze dwie cyfry na nr rewizji).

ad numer rewizji: logicznie rzecz biorąc, nie możesz się powołać na kod źródłowy rev. 5 dla podtrzymania tezy, że to są te same numery, i jednocześnie zignorować go dla podtrzymania tej samej tezy. Bo rev. 5 to jest, o ile mi wiadomo, jedyny kod źródłowy sensu stricto XL OS-u (reszta jest nie źródłowa, tylko źródłowana). Faktem jest, że wcześniejsze numery rewizji w tym źródle się zgadzają z sygnaturą, i faktem jest, że ostatni numer rewizji się z nią nie zgadza. Czyli: jedyne miarodajne źródło w tej dziedzinie, pochodzące wprost od programistów Atari, przeczy twojej tezie, że numery rewizji w źródle i w sygnaturze są te same. Można spekulować, że to pomyłka, że to prototyp i na pewni by sygnaturę uzupełniono itd. ALE FAKT jest taki, że te numery się różnią.

ad 3: ma to sens. Niemniej nadal niewiele to robi, skoro wszystkie modele poza 1200XL mają tam $02. Raczej bym numerację oparł na part number/rev number i dacie.

Generalnie, może poczekamy na jakieś inne głosy w dyskusji? KMK 19:45, 6 wrz 2010 (CEST)

ad1. Twojej spekulacji nie ma potrzeby zbijać, bo jest tylko spekulacją. Fakt jest taki, że dostępna dokumentacja nie stwierdza nic o jednolitości numerowania XL OSu i TOSu. Jak chcesz tworzyć nową konwencję, to opieraj ją na faktach, a nie spekulacjach.

ad2. Nawet jeśli przyjąć Twoją hipotezę, że Atari Corp. zawracało sobie głowę ujednolicaniem numeracji, to zauważ, że przejście z 1.x na 1.0x nastąpiło po 1 stycznia 1990, a więc dawno po zarzuceniu rozwoju XL OS. Dlaczego zatem miałbyś przykładać miarę z lat 90. do produktów powstałych wcześniej? I co to w ogóle za sformułowanie "wygląda konsekwentnie"? Bez zera wiodącego też jest (a nie "wygląda") konsekwentnie, wg zasady "na nr rewizji zawsze tyle cyfr ile potrzeba".

ad numer rewizji: Można spekulować, że programiści umieszczali z sygnaturze numer rewizji a w komentarzach pisali o czymś zupełnie innym itd. ALE FAKT jest taki, że te numery były tym samym, dopóki ktoś we wrześniu 1984 nie zaczął pracy nad rewizją 5, która o zgrozo nie zakończyła się wyprodukowaniem kości ROM o której ktoś kiedyś słyszał.

ad 3: W takiej sytuacji data nie jest już potrzebna.

ad. głosy: To może przenieść dyskusję do Dyskusja:XL OS. --Krótki 22:03, 6 wrz 2010 (CEST)

ad 1: dostępna dokumentacja nie stwierdza tego, bo w ogóle nic nie mówi o systemie numeracji XL OS-u, proszę bez demagogii.

ad 2: dlatego, że 1) taka jest ostateczna wykładnia w sprawie tego systemu, 2) wydało ją z siebie autorytatywne źródło, to znaczy samo Atari. Co do "konsekwencji", jak napisałem, jest to argument praktyczny (na tu i teraz, abstrahując od intencji twórcy systemu, które, jak widać, są trudne do docieczenia): po prostu 1.02 w zestawieniu z 1.59 wygląda "bardziej symetrycznie". Poza tym, dla mnie osobiście "1.2" wygląda jak "1.20" z pominiętym końcowym zerem. Napisanie "1.02" rozwiewa tego typu wątpliwości, gdyby się miały komuś urodzić.

ad nr rewizji: nie, to nie jest fakt, to jest spekulacja. FAKT jest tylko taki, że w źródle pierwsze numery są tożsame z sygnaturą, a ostatni nie. Może (spekulacja) jest to omyłka. Ale równie dobrze może to oznaczać, że to jest po prostu inny system numeracji, którego używali programiści do swojego wewnętrznego użytku.

ad głosy: zrobione. Może się ktoś odezwie. KMK 12:36, 8 wrz 2010 (CEST)

ad 1: Źródła XL OS-u są wystarczającą dokumentacją. Erystyczne zagrywki mające wykazać, że numer rewizji nie jest numerem rewizji, nic tu nie pomogą.

ad 2: Wydało ją z siebie ponad 2 lata po zakończeniu rozwoju, pewnie z rok po wycofaniu się z produkcji software'u na Atari - naprawdę uważasz że rozsądnie jest myśleć, że Atari wtedy jeszcze przejmowało się ujednolicaniem numeracji oprogramowania dawno umarłego?

ad argument praktyczny: to jak coś wygląda to argument estetyczny, a nie praktyczny. Nie wprowadzaj tutaj subiektywnych odczuć. 1.20? Tak mógłby pomyśleć tylko ktoś kto nie wie że kropka w numerze wersji nie oznacza miejsca dziesiętnego. Każdy kto choć trochę miał styczność z oprogramowaniem do takiego wniosku nie dojdzie, nie martw się. Poza tym - to znowu Twoje subiektywne odczucie.

ad nr rewizji: No właśnie rzecz w tym, że nie równie dobrze. To że Twoja hipoteza jest tak samo prawdopodobna jak moja, jest wyłącznie w Twoim mniemaniu.

ad głosy: O, dzięki. --Krótki 20:33, 8 wrz 2010 (CEST)

Mimo czekania jakoś nikt się nie wyrywa, więc chyba będziemy musieli to jakoś rozstrzygnąć sami. Ja chwilowo choruję, pozwolisz, że do tematu wrócimy za parę dni. KMK 22:47, 11 wrz 2010 (CEST)

Życzę szybkiego powrotu do zdrowia.

Biorąc pod uwagę dotychczasowe doświadczenia, nie spodziewam się odzewu w ciągu najbliższych 2 lat. Chodzi mi po głowie, żeby w przypadku tego typu dyskusji dawać jakiś link na stronie głównej Atariki, wyróżniający się - może to by "zaktywizowało" czytelników. Co o tym sądzisz?

Proponuję:

1. Przeedytować niniejszą dyskusję żeby wyraźnie wyartykułować wszystkie za i przeciw (obecnie toną one w gąszczu, z mojej strony czasem niepotrzebnych, komentarzy);

2. W artykule XL OS umieścić obie formy zapisu wersji, zarówno pełną i skróconą (BB000001 Rev. 2, w skrócie BB 1.02) - uważam że możliwie najpełniejsza informacja o numerze wersji (zapis pełny) powinien się w encyklopedii znajdować. Częściowo odzwierciedliłoby to obecną praktykę - atarowcy na świecie (AtariAge, AtariArea) zazwyczaj mówią "OS Rev. n" a nie "OS BB xx.xx". --Krótki 16:48, 12 wrz 2010 (CEST)

Ok, może tak być, ale nawet po długim zastanowieniu sądzę, że "pełna" wersja ma zdecydowanie za dużo zer, co wydatnie obniża jej czytelność. Co do "rev." - oczywiście, trzeba to dodać. KMK 00:34, 7 lut 2011 (CET)

PS. Terminologia używana na AAge etc. nie uzględnia, wydaje mi się, dokładnie wszystkich rewizji (np. BB 1.02 i BB 1.03). KMK 00:35, 7 lut 2011 (CET)