Vlákno názorů k článku Projekt Amiga: herní sestava a srovnání s konkurencí od pavt - Nemyslím, že flame po tolika letech má nějaký...

Nemyslím, že flame po tolika letech má nějaký smysl. Atari ST bylo skvělým počítačem v roce 1985, ale podle mne velice rychle zastaralo, mnohem rychleji, než Amiga a její OS. Kromě toho, autor zde používá A500+, která měla WB2.0, což byl zcela nový level, na který se GEM+TOS nedostal ani ve verzi 4 pro Falcon. V podstatě férovější by bylo srovnání s WB1.3, který se s TOS 1.04 či 1.62 dá snad nějak srovnávat, ale opět, jen částečně. Zatímco TOS byl v podstatě jen grafickým spouštěčem aplikací, WB je operační systém - s příkazovým Shellem, s autostartovým skriptem, s jednoduchou možností vytváření nových zařízení, preemptivním multitaskingem, dlouhými názvy souborů, v případě systému 2 i s podporou retargetable graphics, což TOS opět neuměl atd. Ono mnohé šlo dělat i v TOSu, ale zdaleka ne tak snadno - pokud vím, TOS v základu neměl ani nastavování rychlosti myši, i na to člověk musel sehnat nějakou utilitu.
Co se používání týče, na Amize bylo poměrně běžné mít 2 disketovky, nebo ti bohatší měli HDD. S dvěma disketovkama byla práce mnohem snazší, ale existovaly dvě další možnosti. Jednak má WB standardně k dispozici Ramdisk a ten umí něco, co dodnes nikdo (pokud vím) nikde neudělal - umí nastavovat svou velikost dynamicky podle toho, co do něj uložíte. To pokud vím neexistuje na OSX ani Windows, nevím jak na Linuxu, a je to neuvěřitelně chytrá fičura. Rád si nechám doporučit něco, co to dnes umí, hledám takovou utilitu marně už 30 let. My, co jsme Amigu využívali k práci, jsme si vytvářeli neresetovatelný ramdisk RAD, do kterého jsme si nahráli potřebné části Workbenche, takže jsme při restartu systému měli vše k dispozici hned. To uměl už systém 1.3, pokud vím, TOS nic takového neumí. Jak autor připomíná, start systému na Amize trvá déle, než na ST. To je pravda - ale jen u neupravené standardní diskety systému. Když si s takovou disketou opravdu pohrajete a odstraníte vše nepotřebné (stačí to odstranit ze Startup-sequence, na disketě to může zůstat), je start systému i na Amize velmi rychlý, srovnatelný s ST - v podstatě potřebujete pouze příkaz LoadWB. Osobně kdysi zkoušeno na A500 a WB1.3. Samozřejmě, start systému s RADem je rychlejší. Ve skutečnosti se tedy diskotéka nekonala, respektive, byla srovnatelná s ST.
Problém trošku je, že autor srovnává A500+ s ECS chipsetem s 1040STFM - tedy stroje z jiných dob. ECS chipset vymazal nejdůležitější výhodu ST oproti Amize - skvělý monochromní 640x400 mód. Na ECS jste mohli pracovat v jemnější grafice a ve 4 barvách. Proto si myslím, že zaměření testu na hry je správné - tam se ECS nijak neprojevil.
Správný je komentář, že ST mělo skvělé programy - Cubase a Calamus byly dokonalé a na Amize minimálně v té době asi nebylo nic srovnatelného. Také si myslím, že v dotyčné době (1991) mělo ST i lepší vývojové nástroje. To se později změnilo, i díky tomu, že Amiga jako platforma je dodnes rozšiřovaná a vylepšovaná - akcelerátory, nové verze OS atd.
Nesouhlasím s podceňováním multitaskingu. Pokud člověk tyto počítače používal naplno, multitasking se velmi hodil. ST mělo task switching se svými ACC, to byla jen z nouze ctnost. Různé další vylepšení jako MultiTOS atd jsou pozdější, nestabilní, s problematickou kompatibilitou a na holém 1040STFM by ani nejely. Ano, je pravda, že na strojích s 1MB byly možnosti multitaskingu omezené, ale jakmile bylo paměti víc, bylo to hned vidět.
Po stránce HW měla Amiga dle mne jasně navrch i rozšiřitelností - 500+ má jednak snadno rozšiřitelnou RAM, obsahuje ZORROII slot kam připojíte SCSI disk, akcelerátor či větší rozšíření RAM. To vše se dělalo a standardní 1040STFM to neumělo. Ano, Amiga neměla Midi, ale stačilo koupit bazmek v ceně 500kč, připojit na sériový port a Midi bylo. Ale nebyl Cubase, to je pravda. Nám, amatérům, ale stačil i Bars&Pipes případně OctaMED. Na DTP třeba Pagestream, s Calamusem možná srovnatelný. Opravdu těžko tohle porovnávat, autor udělal dobře, že se soustředil na hry, kde je to snadno viditelné. Každopádně díky za článek, těším se na další!

Děkuji za dlouhý a zajímavý komentář. Jen k tomu dodám - srovnávám počítače, které mám fyzicky v ruce. Je mi jasné, že 500 bez plus by byla adekvátnější k Atari, ale tu nemám, a modernější STe taky ne.

Nicméně mým cílem nebylo říct tenhle počítač je super a tenhle stojí za pytel...Oba jsou skvělé. Spíš šlo prostě vytáhnout pár příkladů, které se dají 1:1 porovnat, jak se lišily u majitelů obou zařízení a další drobné poznatky.

Mám za to, že ramdisk v linuxu má sice pevnou velikost, ale zabírá jen tolik, kolik je na něj uloženo dat. Takže velikost slouží spíš jako horní mez.

Musím se omluvit, linux nepoužívám, máte pravdu, nechal jsem se unést svým srdcem dávného Amigisty:-). Když jsem před cca 12 léty používal Windows, skutečně tam nic dynamického neexistovalo, ale jak jsem se teď díval nyní, ramdisky s dynamickou alokací tam již jsou. Na OSX, který používám, bohužel stále nic podobného není. Neresetovatelný RAD je ale dodnes něco, co moderní počítače neznají - a možná by se to také mohlo hodit, protože to odstraňuje tu největší nevýhodu ramdisku, vymazání dat při restartu. Je ale třeba říct, že RAD si zachoval obsah pouze při klasickém resetu, ne při vypnutí počítače nebo v případě zhroucení systému (na Amize častému).

No, teoreticky by to asi na linuxu možné bylo. Pokud člověk použije v biosu "quick" boot, tak v ram pravděpodobně zůstane předchozí obsah. Takže by nemělo být těžké vyrobit modul, který na předem specifikovaném místu v paměti předá parametry ramdisku pro další běh. (Nebo použít kexec, pak si ale zas člověk koleduje o špatně zinicializovaný hw, protože některé drivery prostě předpokládají stav hw po bootu (nikdy nebyly testovány na hw s jiným stavem). Nicméně v dnešní době je jednodušší prostě uložit stav ramdisku na jiné médium a pak ho odtamtud načíst. My takhle používáme v práci instalační root ramdisky, jejichž obsah se upraveným initrd natáhne po síti. (Což nám dělá teď problém na virtuálech, protože debian buster se nám nevejde do 1G ram, zatímco debian wheezy se vešel do 512mb a ještě zbylo na běh systému.