Dyskusja:XL OS

From Atariki

Wersja z dnia 10:39, 8 wrz 2010 KMK (Dyskusja | wkład) ← Previous diff		Wersja z dnia 18:33, 8 wrz 2010 Krótki (Dyskusja | wkład) (re: poprawiłeś numery wersji) Next diff →
Linia 44:		Linia 44:
	::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 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. [[Użytkownik:KMK|KMK]] 12:36, 8 wrz 2010 (CEST)		::ad głosy: zrobione. Może się ktoś odezwie. [[Użytkownik:KMK|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. --[[Użytkownik:Krótki|Krótki]] 20:33, 8 wrz 2010 (CEST)

---

Wersja z dnia 18:33, 8 wrz 2010

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)