Názory k článku
Magnetické paměti pro trvalý záznam dat
q (neregistrovaný)
24. 7. 2008 0:31
Nový
Re: krasa
celé vlákno
jj .. Tisnovský rulez. Vice takovych autoru by to chtelo. Pekny clanek.
VeselaHouba (neregistrovaný)
24. 7. 2008 7:46
Nový
A co chudinka DLT?
celé vlákno
Zdravim! Moc hezky clanek, ale chybi mi zde alespon okrajova zminka o technologii DLT. Myslim ze to je dnes jedina paskova technologie ktera se jeste na spouste mist pouziva, proto myslim ze by par radku o ni nebylo na skodu.
uživatel si přál zůstat v anonymitě
24. 7. 2008 9:39
Nový
Re: A co chudinka DLT?
celé vlákno
A co LTO? vejde se na ni vic...
Field (neregistrovaný)
24. 7. 2008 13:05
Nový
Re: A co chudinka DLT?
celé vlákno
DLT je fajn, ale DAT (DDS) bylo a stale je urcite rozsirenejsi alespon v retailu a malych serverech. Jaka je situace u vybornych SOny AIT nevim, kdysi pomerne oblibeny Travan uz se nejspis dneska moc nevidi.
Mimochodem, ty jednocivkove devitistope pasky - to byla panecku magie. Natahovalo se to podtlakem pres nejakych sest ci osm napinacich kladek - pozorovat, jak ta paska sama leze a ohyba se v paskove ceste byla docela napinava zabava :-)
Mimochodem, ty jednocivkove devitistope pasky - to byla panecku magie. Natahovalo se to podtlakem pres nejakych sest ci osm napinacich kladek - pozorovat, jak ta paska sama leze a ohyba se v paskove ceste byla docela napinava zabava :-)
24. 7. 2008 10:01
Nový
A jak je to
celé vlákno
s HITACHI Microdrive? Je to obdoba IBM a já se domníval, že je tam rotující kotouček, něco jako u HDD. Používám to ve foťáku.
g.
g.
24. 7. 2008 10:42
Nový
Re: A jak je to
celé vlákno
Jasně, to je maličkatý harddisk, jak píšu v článku (ta podoba s původním ZX Microdrive je pouze v principu magnetického záznamu, jinak je to něco zcela jiného)
potwor (neregistrovaný)
24. 7. 2008 10:03
Nový
"Tapezetor"
celé vlákno
Jooo, nahravani z kazety.. u zx stravil sem tak desitky (podle bratra stovky) hodin u pocitace, pri nahravani mel clovek cas i na jidlo (coz pak odpadlo s prvni disketovkou ;-)), diky nahravani clovek uz vedel podle ucha jestli je to "basic zavadec", "screen, cast atributu", nebo dokonce v bloku dat "blok tabulek, blok grafiky" :-)) jenom tohle odeslo s nastupem kompresnich rutin..
super clanek, cerstve po speccyficke akci mi akorat pridal na nostalgicnosti a povzdechu "Jooo, tenkrat, v casech,kdy nebyl internet...." :-D
super clanek, cerstve po speccyficke akci mi akorat pridal na nostalgicnosti a povzdechu "Jooo, tenkrat, v casech,kdy nebyl internet...." :-D
Grunt (neregistrovaný)
24. 7. 2008 13:18
Nový
Re: "Tapezetor"
celé vláknodiky nahravani clovek uz vedel podle ucha jestli je to "screen, cast atributu"Při
LOAD "" CODE 16384? To by mě teda zajímalo jak. :-)
K. (neregistrovaný)
24. 7. 2008 15:26
Nový
Re: "Tapezetor"
celé vlákno
Kdyz se jednalo o "program", byl zvuk vselijaky, stejne jako data
Kdyz se jednalo o uvodni obrazek, byl zvuk trhany a periodicky, protoze nahozeno bylo jen "par bitu" a opakovaly se po radcich a po periode 8
Kdyz se jednalo o atributy obrazovky, zvuk byl takovy.. melodicky pripadne az jako vrtulove letadlo. Kazdopadne je treba priznat, ze pokud byly atributy nekde v tele, clovek to moc nepoznal, protoze rozdil oproti "programu" nebyl az takovy. Ale kdyz nahravate obrazek, prechod od "grafickych" dat k atributum poznate :-)
Ovsem existovaly i obrazky prakticky nepoznatelne - zvlaste u novejsich her, kde se hojne vyuzivalo "ditheringu". Zabijakem pak samozrejme bylo, kdyz byl obrazek komprimovany.
Kdyz se jednalo o uvodni obrazek, byl zvuk trhany a periodicky, protoze nahozeno bylo jen "par bitu" a opakovaly se po radcich a po periode 8
Kdyz se jednalo o atributy obrazovky, zvuk byl takovy.. melodicky pripadne az jako vrtulove letadlo. Kazdopadne je treba priznat, ze pokud byly atributy nekde v tele, clovek to moc nepoznal, protoze rozdil oproti "programu" nebyl az takovy. Ale kdyz nahravate obrazek, prechod od "grafickych" dat k atributum poznate :-)
Ovsem existovaly i obrazky prakticky nepoznatelne - zvlaste u novejsich her, kde se hojne vyuzivalo "ditheringu". Zabijakem pak samozrejme bylo, kdyz byl obrazek komprimovany.
Grunt (neregistrovaný)
24. 7. 2008 16:10
Nový
Re: "Tapezetor"
celé vlákno
Samozřejmě, škrkání při načítání SCREEN$ už do smrti nedostanu z hlavy. Já se jen ptám jak poznáte podle zvuku, když prostě kód určený ke spuštění naperu do VIDEORAM jestli se jedná o obrázek nebo ne. Na obrazovku se to vykreslí, takže to obrázek bude(i když bude vypadat jako z funkce RND).
uživatel si přál zůstat v anonymitě
24. 7. 2008 16:47
Nový
Re: "Tapezetor"
celé vlákno
autor prechozich prispevku mluvi pravdepodobne o ZX spectrum, ci Didaktiku a vy o Atari? Na ZX to slo opravdu rozeznat, dokonce s trochou zkusenosti bylo mozne podle zvuku rozeznat ze se jedna o poskozenou cast zaznamu a loader selze, pokud jste treba rovnou jedl v druhe mistnosti ;)
Grunt (neregistrovaný)
24. 7. 2008 17:14
Nový
Re: "Tapezetor"
celé vlákno
VIDEORAM na adrese 16384 a Atari? Samozřejmě, že se bavím o Didaktiku. Ale nechme toho.
24. 7. 2008 17:19
Nový
Re: "Tapezetor"
celé vlákno
Proč ne, klidně se tam na Atárku dá posunout :-) Ale ten příkaz LOAD by asi neprošel :-), nehledě na to, že klasická Atarácká Turba při nahrávání měly vypnutý obraz, maximálně se měnila barva paprsku (to byly ony černobílé pruhy u Turba 2000 a barevné u Super Turba).
24. 7. 2008 17:20
Nový
Re: "Tapezetor"
celé vlákno
"Turba měla" ne "Turba měly", nějak mi to dnes nemyslí...
olaf (neregistrovaný)
24. 7. 2008 19:29
Nový
Re: "Tapezetor"
celé vlákno
je to strasna nostalgie ted jsem si vzpomel jak me tata liskal za to, ze jsem u atarka zapomel po nahrani vypnout play a ta pritracna kladka vymackla do pasku ryhu :)
Anebo jeste bez turba se to nahravalo 20 min a sup load error .
hm to se delo nekdy v roce 86 :-) nemel jsem ani kazetak takze prisel "king" (v te dobe jsem mel 6 let) nahral zorro, miner, pitstop, hero apod. a dokud neblikla elektrika tak cela rodina hrala hodiny a hodiny :) .
Nicmene cela ta vec s ATARI a kazetakem ma mozna pozadi o kterem se moc nevi , ale fy. ATARI kazetak neplanovala a na zapad od nas se od zacatku pouzivala disketovka jenze mam pocit , ze pro zeme varsavske smlouvy bylo dovazet disketovky znemozneno kvuli know how .
Anebo jeste bez turba se to nahravalo 20 min a sup load error .
hm to se delo nekdy v roce 86 :-) nemel jsem ani kazetak takze prisel "king" (v te dobe jsem mel 6 let) nahral zorro, miner, pitstop, hero apod. a dokud neblikla elektrika tak cela rodina hrala hodiny a hodiny :) .
Nicmene cela ta vec s ATARI a kazetakem ma mozna pozadi o kterem se moc nevi , ale fy. ATARI kazetak neplanovala a na zapad od nas se od zacatku pouzivala disketovka jenze mam pocit , ze pro zeme varsavske smlouvy bylo dovazet disketovky znemozneno kvuli know how .
sql1 (neregistrovaný)
24. 7. 2008 21:51
Nový
Re: "Tapezetor"
celé vlákno
presne tak :-) Ja mam velmi rad tie zvuky, kedysi som sa toho napocuval hodne ...
A super je, ze pre ZX Spectrum existuju viacmenej dokonale emulatory, ktore emuluju aj pasku, daju sa stiahnut dokonca presne kopie zabezpecenych originalnych hier (format .TZX) kde je zachovany zaznam roznych speedloaderov a pod.
Emulatory sa daju dokonca nastavit aby "virtualnu pasku" prehravali v realnom case, spolu so zvukmi ...
Velmi odporucam napr. www.spectaculator.com
je to sice plateny soft, ale stoji to za to (k stiahnutiu je trial verzia)
vsetkym milovnikom ZX Spectra vrelo odporucam :)
A super je, ze pre ZX Spectrum existuju viacmenej dokonale emulatory, ktore emuluju aj pasku, daju sa stiahnut dokonca presne kopie zabezpecenych originalnych hier (format .TZX) kde je zachovany zaznam roznych speedloaderov a pod.
Emulatory sa daju dokonca nastavit aby "virtualnu pasku" prehravali v realnom case, spolu so zvukmi ...
Velmi odporucam napr. www.spectaculator.com
je to sice plateny soft, ale stoji to za to (k stiahnutiu je trial verzia)
vsetkym milovnikom ZX Spectra vrelo odporucam :)
Boogie (neregistrovaný)
24. 7. 2008 22:05
Nový
Re: "Tapezetor"
celé vlákno
A pro linuxaky tohle http://fuse-emulator.sourceforge.net/ umi snad vsechno co ma umet ZX emulator, dokonce i multicolory v demech. A je zadara :)
bredy.jinak.cz (neregistrovaný)
25. 7. 2008 13:04
Nový
Re: "Tapezetor"
celé vlákno
Konstantní vysoké pískání a úzké pruhy = nulový blok (blok vyplněný nulama)
Konstantní nižší pískání a široké pruhy = jedničkový blok
Chrčení s pískajícím pozadím (chrííchrííchríííchríííchrííí .... ) tak to je pravděpodobně BASIC, protože
veškeré celočíselné konstanty byly zarovnány nulama 00 00 HI LO 00 00
Opakovaní přerušované pískání (píí-pri-pri-pri-píípíííí-píí-pri-pri-pri-píípíííí-píí-pri-pri-pri-píípíííí), zvlášť pokud to bylo zakončeno tradiční fází "hreeeeedududududdududYYYYdYYYdYYY".... na 99% obrazová data zakončená blokem atributů... je to dáno tím, že obrazovka byla rozdělená po třetinkách a přenášela se každá osmá řádka... proto se vždy 8x opakovalo pískáni, jelikož obrázek míva řádky vedle sebe podobné. Třikrát se tedy změnilo pravidelné pípání a pak následovala oblas atributů, které byly složeny ve formě FBPPPIII (Flash, Bright, Paper, Ink) a ta čísla se na plochách opakovala.
Pravidelné pípání delší víckrát než 8x a pokud nebylo slyšet třetinky, tak to zpravidla bývala data v nějakých tabulkách
Pokud bylo slyšet iiiiiigraugraugraugreugryigriiiiiiiiiigraugraugraugreugryigriii tak to pravděpodobně mohly být sprajty, nebo grafika.
Když signál kolísal IIIiiiiiiooouuuuuuuuooooiiiiiiioooouuuuuuu, tak člověk trnul, aby se na konci neobjevilo Tape Loading Error. Loader byl schopen dlouhou dobu (celých 5minut) přijímat chybná data, až na konci zjistil, že mu nesedi checksum. To bylo pravda trošku nepraktické
Monotoní chrčení pak znamenalo buď programový kód, nebo komprimovaná data, případně něco nepoznatelného
Pamětník určitě rád vzpomene na TUUUUUUUUUUUUUUUKřk...... TUUUUUUUUkkřiřkřikřikřikřikřiřkřiřiiřkřiřikřřř........TUUUUUUUUUUUkřk... TUUUUUUUUUUUUUUUUUUpíí-pri-pri-pri-píípíííí-píí-pri-pri-pri-píípíííí-píí-pri-pri-pri-píípíííí (screen) doprovázen popisky na obrazovce
Progam: Space
Bytes: Space
Mimochodem, kdyby se vynechala část obsahující screen, hra by často nabíhala o cca minutu kratší
Moderní loadery obsahovaly rutinku, co vymalovala obrazovku čtverečkem, tyto data šla taky poznat protože to bylo něco ve styly: chrechrechrechrichrochrechrechrycha... pravidelně opakující se hlavička čtverečku nasledovaná daty. Nutno podotknout, že tyto screeny nabíhaly nejdéle. Efekt byl pěkný, ale nahrávání to spíš zpomalilo
Konstantní nižší pískání a široké pruhy = jedničkový blok
Chrčení s pískajícím pozadím (chrííchrííchríííchríííchrííí .... ) tak to je pravděpodobně BASIC, protože
veškeré celočíselné konstanty byly zarovnány nulama 00 00 HI LO 00 00
Opakovaní přerušované pískání (píí-pri-pri-pri-píípíííí-píí-pri-pri-pri-píípíííí-píí-pri-pri-pri-píípíííí), zvlášť pokud to bylo zakončeno tradiční fází "hreeeeedududududdududYYYYdYYYdYYY".... na 99% obrazová data zakončená blokem atributů... je to dáno tím, že obrazovka byla rozdělená po třetinkách a přenášela se každá osmá řádka... proto se vždy 8x opakovalo pískáni, jelikož obrázek míva řádky vedle sebe podobné. Třikrát se tedy změnilo pravidelné pípání a pak následovala oblas atributů, které byly složeny ve formě FBPPPIII (Flash, Bright, Paper, Ink) a ta čísla se na plochách opakovala.
Pravidelné pípání delší víckrát než 8x a pokud nebylo slyšet třetinky, tak to zpravidla bývala data v nějakých tabulkách
Pokud bylo slyšet iiiiiigraugraugraugreugryigriiiiiiiiiigraugraugraugreugryigriii tak to pravděpodobně mohly být sprajty, nebo grafika.
Když signál kolísal IIIiiiiiiooouuuuuuuuooooiiiiiiioooouuuuuuu, tak člověk trnul, aby se na konci neobjevilo Tape Loading Error. Loader byl schopen dlouhou dobu (celých 5minut) přijímat chybná data, až na konci zjistil, že mu nesedi checksum. To bylo pravda trošku nepraktické
Monotoní chrčení pak znamenalo buď programový kód, nebo komprimovaná data, případně něco nepoznatelného
Pamětník určitě rád vzpomene na TUUUUUUUUUUUUUUUKřk...... TUUUUUUUUkkřiřkřikřikřikřikřiřkřiřiiřkřiřikřřř........TUUUUUUUUUUUkřk... TUUUUUUUUUUUUUUUUUUpíí-pri-pri-pri-píípíííí-píí-pri-pri-pri-píípíííí-píí-pri-pri-pri-píípíííí (screen) doprovázen popisky na obrazovce
Progam: Space
Bytes: Space
Mimochodem, kdyby se vynechala část obsahující screen, hra by často nabíhala o cca minutu kratší
Moderní loadery obsahovaly rutinku, co vymalovala obrazovku čtverečkem, tyto data šla taky poznat protože to bylo něco ve styly: chrechrechrechrichrochrechrechrycha... pravidelně opakující se hlavička čtverečku nasledovaná daty. Nutno podotknout, že tyto screeny nabíhaly nejdéle. Efekt byl pěkný, ale nahrávání to spíš zpomalilo
Clock (neregistrovaný)
24. 7. 2008 10:25
Nový
Rekonstrukce programu z diskety
celé vlákno
Jako vsechno, magneticka media funguji krasne v laboratori, ale kdyz z nich chce clovek precist neco dulezite po mnoha letech, jde to do prdele.
Jsem po asi 12 letech se snazil rekonstruovat hru na Didaktika kterou jsem napsal a ktera nikde nebyla. Byla nahrana na 80-stopy diskete 5 1/4. Toz jsem koupil disketovku D40, sehnal 80-stopu mechaniku z prodejny s pouzitymi pocitaci (fakt zazrak, dneska se to uz nikde nevyskytuje) a zjistil ze hovno. Mechanika byla vadna, mela maly pritlak, disketa prokluzovala na hubu.
Tak jsem tam nekam narval kus papundeklu z praciho prasku a disketa se zacla tocit spravnou rychlosti. Ale stejne to cetlo samy errory. Tak jsem dlouho nevedel co s tim az jsem si vsimnul trimmeru, ktery zrejme nejak nastavoval fazovy zaves. Tak jsem s tim nejak potocil a ono to v urcite pozici zaclo chodit. Rychle jsem nahral potrebna data a napul rozsroubovanou disketovku hodil do sklepa a uz na ni nesah.
Vysledek rekonstrukce je na http://ronja.twibright.com/jswx.php
Jsem po asi 12 letech se snazil rekonstruovat hru na Didaktika kterou jsem napsal a ktera nikde nebyla. Byla nahrana na 80-stopy diskete 5 1/4. Toz jsem koupil disketovku D40, sehnal 80-stopu mechaniku z prodejny s pouzitymi pocitaci (fakt zazrak, dneska se to uz nikde nevyskytuje) a zjistil ze hovno. Mechanika byla vadna, mela maly pritlak, disketa prokluzovala na hubu.
Tak jsem tam nekam narval kus papundeklu z praciho prasku a disketa se zacla tocit spravnou rychlosti. Ale stejne to cetlo samy errory. Tak jsem dlouho nevedel co s tim az jsem si vsimnul trimmeru, ktery zrejme nejak nastavoval fazovy zaves. Tak jsem s tim nejak potocil a ono to v urcite pozici zaclo chodit. Rychle jsem nahral potrebna data a napul rozsroubovanou disketovku hodil do sklepa a uz na ni nesah.
Vysledek rekonstrukce je na http://ronja.twibright.com/jswx.php
24. 7. 2008 10:44
Nový
Re: Rekonstrukce programu z diskety
celé vlákno
Tyjo, ja na Atárku ještě všecho přečtu. Taky 5 1/4 diskety, ale pravda pouze poloviční kapacity. Po těch 20 letech funguje skoro všechno. Kazety už nemám, ty později padly na záznam hudby :-(
MAd MAx (neregistrovaný)
26. 7. 2008 14:16
Nový
Re: Rekonstrukce programu z diskety
celé vlákno
Jo Jo Atari malo dobry format diskiet - velke a mala kapacita takze asi aj to poma v ich vyssej citatelnosti ako keby tam bola vysoka hustota zaznamu. Kazety boly ale bieda sama o sebe - zla schopnost nahravania dat + nekonecne pretacanie bol to des, osobne som pouzival len turbo 2000 klasicku rychlost som nikdy nezazil lebo som mal cartridge v ktorom to turbo bolo nahrane :)
Zaujimave je ze to svoje Atari tak raz za 3 roky pustim a ono este furt funguje a z diskiet aj loaduje. Inak ho skor uzijem emulovane - predsa len nepoznam ziadneho akrivneho osemstovkara s ktorym by som si menil soft a na nete je toho tak vela co ani nepoznam...
Zaujimave je ze to svoje Atari tak raz za 3 roky pustim a ono este furt funguje a z diskiet aj loaduje. Inak ho skor uzijem emulovane - predsa len nepoznam ziadneho akrivneho osemstovkara s ktorym by som si menil soft a na nete je toho tak vela co ani nepoznam...
uživatel si přál zůstat v anonymitě
24. 7. 2008 11:25
Nový
Re: Rekonstrukce programu z diskety
celé vlákno
D40 je divna. co si pamatuju, tak se tam kus zpracovani dat resil v sw a kus v hw, takze zaznam podle toho vypadal. brr..
po prechodu na i386 jsem si napsal soft na dekodovani spektrackych zaznamu z kazet do TAPu, to by mohlo pomoct pri rekonstrukci dat z kazet (vstup je wav, vystup tap a ten soft ma pomerne velkou toleranci na poskozeni zaznamu).
po prechodu na i386 jsem si napsal soft na dekodovani spektrackych zaznamu z kazet do TAPu, to by mohlo pomoct pri rekonstrukci dat z kazet (vstup je wav, vystup tap a ten soft ma pomerne velkou toleranci na poskozeni zaznamu).
24. 7. 2008 11:26
Nový
Re: Rekonstrukce programu z diskety
celé vlákno
pardon, nepodepsal jsem se :-)
24. 7. 2008 12:28
Nový
Re: Rekonstrukce programu z diskety
celé vlákno
Já mám magnetický záznam radši, než nějaká CD, či DVD, které nic nevydrží. 10 let mám hudbu na MiniDisc-u a vše je krásně funkční. To samé u 2 roky starého DVD tvrdit nemůžu :-/
Field (neregistrovaný)
24. 7. 2008 13:08
Nový
Re: Rekonstrukce programu z diskety
celé vlákno
Je to tak. Citim se lip, kdyz mam fotky vysypane na paskach, nez kdyz jsou na pevnych discich nebo nedejboze na CD ci DVD.
android (neregistrovaný)
24. 7. 2008 10:43
Nový
MZ-821
celé vlákno
Pri pohledu na fotku Sharpa MZ-821 mi skoro ukapla slza.
MiV (neregistrovaný)
27. 7. 2008 23:57
Nový
Re: MZ-821
celé vlákno
Jojo, také jsem ho měl a stále na něj vzpomínám jako na první lásku, bóže, to už je let... Hry Flappy a Moty byly moje nejoblíbenější... krása, i dnes by se uchytily...
bredy.jinak.cz (neregistrovaný)
24. 7. 2008 11:37
Nový
Re: Historie CERNu
celé vlákno
Podobně velké disky jsem viděl v TOS Hostivař někdy kolem roku 1994, kde ještě dosluhovaly. Byly to ruské disky, obrovské bedny s výměnou kazetou (uvnitř obrovský disk) a po zasunutí, zamknutí a zapnutí to nabíhalo asi 5 minut za dobrovodu zvuku startující stíhačky až se na panelu rosvítilo velké zelené tlačítko "ГОТОВ"
Občas si tamní jediný správce "serverovny" stěžoval, že disky nejsou vystředěné a že po roztočení "šmajdaj" takže z nich nejde skoro nic přečíst. Mám pocit, že měli neuvěřitelnou kapacitu 2 (dva) megabajty.
Občas si tamní jediný správce "serverovny" stěžoval, že disky nejsou vystředěné a že po roztočení "šmajdaj" takže z nich nejde skoro nic přečíst. Mám pocit, že měli neuvěřitelnou kapacitu 2 (dva) megabajty.
Field (neregistrovaný)
24. 7. 2008 13:10
Nový
Re: Historie CERNu
celé vlákno
Matne si vzpominam, jak se nekdy koncem osmdesatych let chodilo na servis disku s osciloskopem. Tenkrat byly k servisu pocitacu potreba ponekud jine znalosti :-)
mm (neregistrovaný)
24. 7. 2008 15:31
Nový
Re: Historie CERNu
celé vlákno
Tenkrat byly k servisu pocitacu treba znalosti a lide, kteri je servisovali neco znali.
Srovnajme to s dnesnim typickym uhrovitym PC servisakem :-), ktery zpravidla ani nema tuseni co to vlastne pocitac je...
Srovnajme to s dnesnim typickym uhrovitym PC servisakem :-), ktery zpravidla ani nema tuseni co to vlastne pocitac je...
ToM (neregistrovaný)
24. 7. 2008 18:44
Nový
Re: Historie CERNu
celé vlákno
Konec osmdesátých? Já viděl "instalovat osciloskopem" nový superpočítač koncem devadesátých.
Kvakor (neregistrovaný)
24. 7. 2008 15:36
Nový
Re: Historie CERNu
celé vlákno
Ano, vzhledek k jejich velkym hmotam se chovaly temer jako zdimacka, pri urcitych seekovacih sekvencih se dokonce mohli pohybovat. Podle ESR se dokonce poradali i "zavody disku", viz http://www.catb.org/jargon/html/W/walking-drives.html :-)
Ja sam mel kdysi davno jeste ne-ID disk (80MB Seagate s radicem ST-506), vysoky jako dve 5.25" mechainky a se spotrebou az 4A na 12V vetvi, ktery byl pri plnem seekovani schopen rozvibrovat predmety lezici na stole spolu s pocitacem - sklenicky cinkaly, kulate tuzky se kutaleli a dokonce se obcas trasl i obraz na monitoru :-)
Ja sam mel kdysi davno jeste ne-ID disk (80MB Seagate s radicem ST-506), vysoky jako dve 5.25" mechainky a se spotrebou az 4A na 12V vetvi, ktery byl pri plnem seekovani schopen rozvibrovat predmety lezici na stole spolu s pocitacem - sklenicky cinkaly, kulate tuzky se kutaleli a dokonce se obcas trasl i obraz na monitoru :-)
pc2005 (neregistrovaný)
1. 8. 2008 15:56
Nový
Re: Historie CERNu
celé vlákno
To jde i dnes. Já nemám novou CD/DVD mechaniku přišroubovanou a při vysokých otáčkách se mírně hýbe a je značně cítit vibrování stolu.
Cibulak (neregistrovaný)
24. 7. 2008 20:36
Nový
Re: Historie CERNu
celé vlákno
Disky mali kapacitu 5MB a po stranach stredoveho kotuca mali sektorove vyrezy...
Jeden vymenny (5MB) a jeden spodny nevymenny (5MB), ktory bol v mechanike zabudovany napevno...
Este mam niekde servis manual na tie disky...
Dost casto tam odchadzal fotoclen na regulaciu otacok. V zdroji boli pekne vykonove KD503-ojky..
A myslim, ze neboli ruske ale bulharske...
Jeden vymenny (5MB) a jeden spodny nevymenny (5MB), ktory bol v mechanike zabudovany napevno...
Este mam niekde servis manual na tie disky...
Dost casto tam odchadzal fotoclen na regulaciu otacok. V zdroji boli pekne vykonove KD503-ojky..
A myslim, ze neboli ruske ale bulharske...
bredy.jinak.cz (neregistrovaný)
25. 7. 2008 12:39
Nový
Re: Historie CERNu
celé vlákno
To je možný, je to dávno, navíc jsem to neštudoval. Možná že měli 5MB, ale matně si vzpomínám, že si tam stěžovali, že jim více než půlka nejde přečíst.
Na to, že tam vlastně byly dva si teď vzpomínám. Samozřejmě, že mohly být bulharský, já si prostě pamatuju, že tam byly všechny popisky azbukou ("ГОТОВ" mne ale tak zaujalo, že to jediný mi utkvělo v paměti nejvíc).
Jo a hrál jsem tam na terminálu nějakou textovu, čert ví už o čem byla.
Na to, že tam vlastně byly dva si teď vzpomínám. Samozřejmě, že mohly být bulharský, já si prostě pamatuju, že tam byly všechny popisky azbukou ("ГОТОВ" mne ale tak zaujalo, že to jediný mi utkvělo v paměti nejvíc).
Jo a hrál jsem tam na terminálu nějakou textovu, čert ví už o čem byla.
25. 7. 2008 12:51
Nový
Re: Historie CERNu
celé vlákno
Že by známá "Adventure"? Ta se i u nás docela pařila (znám pouze z doslechu, osobně jsem začínal až na osmibitech).
Grunt (neregistrovaný)
24. 7. 2008 12:57
Nový
RE: Magnetické paměti pro trvalý záznam dat
celé vlákno
Až mi ukápla slza při čtení článku…zvláště když nějakou náhodu vyšla řada na Acidjazzed Evening.
uživatel si přál zůstat v anonymitě
24. 7. 2008 13:20
Nový
ustálení průměrů disků na čtyřech téměř standardních hodnotách
celé vlákno
Nádherný článek, byť jsem v něm hodně poznával Wikipedii :-)
Akorát bych se pozastavil na těch čtyřech hodnotách. Co 2,5" disky? Samozřejmě se nepohybuji v oblasti mainframů, ale 2,5" nádher mám kolem sebe desítky (notebooky, přehrávače apod.), zatímco první zmiňovaný formát jsem neviděl nikdy a druhý naposledy v roce 1990 na Karlově univerzitě.
Akorát bych se pozastavil na těch čtyřech hodnotách. Co 2,5" disky? Samozřejmě se nepohybuji v oblasti mainframů, ale 2,5" nádher mám kolem sebe desítky (notebooky, přehrávače apod.), zatímco první zmiňovaný formát jsem neviděl nikdy a druhý naposledy v roce 1990 na Karlově univerzitě.
24. 7. 2008 14:57
Nový
Re: ustálení průměrů disků na čtyřech téměř standardních hodnotách
celé vlákno
No z Wikipedie jsou spíš obrázky, více informací jsem bral z té první knížky, sice postarší ale dobré: Karel Krištoufek: Kurs číslicových počítačů a mikropočítačů, a samozřejmě jsem také zavzpomínal na doby osmibitů, kdy majitelé disketové jednotky byla šlechta.
Jinak k těm 2,5" diskům - ten rozměr určitě není z dob mainframů, takový průměr mohly mít maximálně tak osy tehdejších disků :-), ale co si pamatuji, tak s nimi (2,5") poprvé přišla IBM, takže nějaké spojení s mainframy tam je.
Ten druhý "největší" disk (průměrem, ne kapacitou) běžel ještě nedávno v jedné firmě v Brně, byl tam připojený k ADTčku a šlapal jak hodinky nepřetržitě téměř 25 let. Byl to docela hukot, samotných ploten bylo snad 12 a pěkně to vrčelo.
Jinak k těm 2,5" diskům - ten rozměr určitě není z dob mainframů, takový průměr mohly mít maximálně tak osy tehdejších disků :-), ale co si pamatuji, tak s nimi (2,5") poprvé přišla IBM, takže nějaké spojení s mainframy tam je.
Ten druhý "největší" disk (průměrem, ne kapacitou) běžel ještě nedávno v jedné firmě v Brně, byl tam připojený k ADTčku a šlapal jak hodinky nepřetržitě téměř 25 let. Byl to docela hukot, samotných ploten bylo snad 12 a pěkně to vrčelo.
sql1 (neregistrovaný)
24. 7. 2008 14:31
Nový
MGF paska
celé vlákno
toto ma zaujima .... myslite si, ze pri dnesnych znalostiach by bolo mozne vytvorit nejaky lepsi system ukladania dat na normalnu audio-kazetu a s klasickym magnetofonom, ak by sa pouzili nejake finty zname z modemoveho prenosu?
Prve modemy mali totiz rychlost podobnu ako prenos z kazety do ZX Spectra, a vyvinuli sa postupne az na 56kbit/s.
A pritom telefonne linky maju omnoho mensie frekvencne pasmo, ako klasika kazeta.
Prve modemy mali totiz rychlost podobnu ako prenos z kazety do ZX Spectra, a vyvinuli sa postupne az na 56kbit/s.
A pritom telefonne linky maju omnoho mensie frekvencne pasmo, ako klasika kazeta.
24. 7. 2008 14:51
Nový
Re: MGF paska
celé vlákno
Podle by se to určitě zlepšilo, vidět je to i na pevných discích (to, co přečtou hlavičky a přenesou vstupní zesilovače, se od krásných obdélníčků dost liší a přichází na řadu DSPčko). Sice je kazeta trošku jiné médium než modem, například nelze jednoduše opakovat chybný přenos, tak má, jak píšeš, větší kmitočtové pásmo a také větší odstup signálu od šumu.
Michal Kára (neregistrovaný)
24. 7. 2008 17:35
Nový
Re: MGF paska
celé vlákno
Urcite by to slo (Implementovat PSK modulaci (?)), ale je otazka, jaky by to melo smysl. A v osmdesatych letech by s implementaci asi byl problem v cene specializovanych obvodu.
pc2005 (neregistrovaný)
1. 8. 2008 16:03
Nový
Re: MGF paska
celé vlákno
To by mě taky zajímalo (kazeta 90minut stereo): 56kbit/s * (60*90)*2 = 604Mbit?
Kyknos (neregistrovaný)
24. 7. 2008 15:34
Nový
Paměťové médium pro ZX Microdrive je zobrazeno na následujícím obrázku zhruba ve své skutečné velikosti.
celé vlákno
...hm a na jakém monitoru, s jakým rozlišením? :)
24. 7. 2008 16:05
Nový
Re: Paměťové médium pro ZX Microdrive je zobrazeno na následujícím obrázku zhruba ve své skutečné velikosti.
celé vlákno
To není potřeba znát, stačí údaj, že obrázek má 96 DPI.
Kyknos (neregistrovaný)
24. 7. 2008 18:27
Nový
Re: Paměťové médium pro ZX Microdrive je zobrazeno na následujícím obrázku zhruba ve své skutečné velikosti.
celé vlákno
to samozrejme staci, diky :)
24. 7. 2008 18:34
Nový
Re: Paměťové médium pro ZX Microdrive je zobrazeno na následujícím obrázku zhruba ve své skutečné velikosti.
celé vlákno
Nj. je to obecný problém, prakticky všechny prohlížeče zobrazují obrázky přesně na pixely (pixely 1:1, rozměry kvůli tomu nesedí). V tomto případě by bylo lepší, kdyby se z DPI vypočítala skutečná velikost a obrázky se přerastrovaly podle nastavené DPI v Tvém systému. Nebo tam můžu dokreslit měřítko :-)
25. 7. 2008 11:48
Nový
Re: Paměťové médium pro ZX Microdrive je zobrazeno na následujícím obrázku zhruba ve své skutečné velikosti.
celé vlákno
Mno, ovšem na obrázky interpolované pomocí nejbližšího souseda bych se dívat nechtěl, a představa že firefox, který již dnes dokáže při prohlížení webu plně vytížit třígigahertzový dvoujádrový procesor, používá nějakou náročnější interpolaci, mě děsí. To abych si pak na prohlížení webu pořídil nějaký superpočítač :))
25. 7. 2008 12:09
Nový
Re: Paměťové médium pro ZX Microdrive je zobrazeno na následujícím obrázku zhruba ve své skutečné velikosti.
celé vlákno
Možná by stačilo, aby to FF předal API grafického subsystému. Ve WinAPI to funguje celkem dobře (myslím ta interpolace, přes StretchDIBits, jestli se dobře pamatuji na správné jméno funkce) a na Linuxu to dnešní Compiz apod. vychytávky dokážou vyřešit přímo na grafické kartě přes stretching textur.
25. 7. 2008 12:14
Nový
Re: Paměťové médium pro ZX Microdrive je zobrazeno na následujícím obrázku zhruba ve své skutečné velikosti.
celé vlákno
Abych moc nekecal, tak API k Compizu nemam vyzkousene, jak to bude v realu rychle.
Ondrej 'SanTiago' Zajicek (neregistrovaný)
25. 7. 2008 16:05
Nový
Re: Paměťové médium pro ZX Microdrive je zobrazeno na následujícím obrázku zhruba ve své skutečné velikosti.
celé vlákno
> V tomto případě by bylo lepší, kdyby se z DPI vypočítala skutečná velikost a obrázky se přerastrovaly podle nastavené DPI v Tvém systému.
Coz by mohlo vest k takovym nesmyslum, jako ze kdyz si nekdo bude danou stranu promitat na dataprojektoru (kde tedy bude minimalni DPI) a bude mit spravne nastavene DPI, tak se mu obrazek smrskne na par pixelu. Udavat vzdalenosti na monitoru v prirozenych jednotkach (mm) neni o moc lepsi nez v pixelech.
Coz by mohlo vest k takovym nesmyslum, jako ze kdyz si nekdo bude danou stranu promitat na dataprojektoru (kde tedy bude minimalni DPI) a bude mit spravne nastavene DPI, tak se mu obrazek smrskne na par pixelu. Udavat vzdalenosti na monitoru v prirozenych jednotkach (mm) neni o moc lepsi nez v pixelech.
25. 7. 2008 16:23
Nový
Re: Paměťové médium pro ZX Microdrive je zobrazeno na následujícím obrázku zhruba ve své skutečné velikosti.
celé vlákno
To je ovšem obecně neřešitelný problém - jak třeba bude na dataprojektoru vypadat stránka, na které mám obdélník (dejme tomu div) s rozměry 10x10cm? Správně bych asi měl mít pro media-type=screen tyto rozměry a pro projektor něco založeného na procentech, ale opět - který OS toto podporuje a který projektor mu vrací zpět rozměry promítané plochy (měření vzdálenosti od projekční plochy)?
Ondrej \'SanTiago\' Zajic (neregistrovaný)
25. 7. 2008 20:18
Nový
Re: Paměťové médium pro ZX Microdrive je zobrazeno na následujícím obrázku zhruba ve své skutečné velikosti.
celé vlákno
No pointa je v tom, ze proste prirozene jednotky nejsou o moc lepsi reseni nez pixely a snazit se o neco takoveho je marna snaha. DPI nejlepe ignorovat, maximalne provadet hrubou korekci (celociselne nasobky) pri vyraznem rozdilu oproti obvykle uhlove velikosti pixelu.
Kyknos (neregistrovaný)
25. 7. 2008 23:24
Nový
Re: Paměťové médium pro ZX Microdrive je zobrazeno na následujícím obrázku zhruba ve své skutečné velikosti.
celé vlákno
mno, to by me zajimalo, čo je to taká obvyklá úhlová velikost pixelu - ta je také pokaždé jiná
Pavel Tišnovský (neregistrovaný)
26. 7. 2008 9:45
Nový
Re: Paměťové médium pro ZX Microdrive je zobrazeno na následujícím obrázku zhruba ve své skutečné velikosti.
celé vlákno
Možná si trošku nerozumíme - je jasné, že obecně tento problém vyřešit nejde (tj. donutit každého, aby ten obrázek zobrazil vždy o daných rozměrech), už jen z toho důvodu, že třeba onen projektor nedává systému zpětně informaci, jaké má DPI, resp. jakou má velikost pixelu, sám projektor tuto informaci také v naprosté většině případů neví.
Ale v případě, že se čtenář ptá na skutečnou velikost obrázku, tak samozřejmě je možné odpovědět. Jak s onou informací naloží, ovšem nikdo dopředu neví.
Zkusím dát příklad: například na web umístím návrh nějakého plošného spoje a aby se neřeklo, tak jeho základní rozměry pro jistotu okótuji (šířka, délka). Ostatní struktury plošňáku, tj. jednotlivé cestičky a pájecí body okótovány nejsou. Na webu ten plošňák bude například ve formátu PDF, PostScript nebo SVG - u těchto formátů jsou použity fyzické rozměry, ne logické, takže případný čtenář má možnost (ne povinnost) si daný plošňák vytisknout ve skutečných rozměrech, zobrazit si jej na obrazovce v měřítku 1:1 (10cm bude opravdu na obrazovce rovno 10cm) apod. Když si však ten stejný plošňák promítne projektorem na stěnu, získá tak třeba 20x větší obrázek, ale asi se nepředpokládá, že právě tento obrázek převede na plošňák - místo kapesní kalkulačky by tak postavil kus Eniacu :-)
To stejné, i když možná ve skrytější podobě, je s rastrovými obrázky. Když ten plošňák bude zveřejněný ve formátu PNG a v jeho hlavičce bude korektně vyplněno DPI, je možné (a netrvrdím, že každá aplikace to zvládne, to zcela jistě ne) ho zobrazit v měřítku 1:1 oproti originálu, což bude prakticky vždy znamenat přepočítávání původních pixelů na pixely obrazovky či tiskové body tiskárny. Ale v každém případě - opět tam ta informace o rozměrech je, záleží na příjemci informace, jak s ní založí.
Bohužel jsem zatím nepřišel na to, jak v redakčním systému zapsat styl u obrázku, tj. něco na způsob style="width:8cm;height:6cm", tím by to bylo vyřešené pro všechny moderní OS - ty totiž DPI svého grafického režimu povětšinou znají.
Ale v případě, že se čtenář ptá na skutečnou velikost obrázku, tak samozřejmě je možné odpovědět. Jak s onou informací naloží, ovšem nikdo dopředu neví.
Zkusím dát příklad: například na web umístím návrh nějakého plošného spoje a aby se neřeklo, tak jeho základní rozměry pro jistotu okótuji (šířka, délka). Ostatní struktury plošňáku, tj. jednotlivé cestičky a pájecí body okótovány nejsou. Na webu ten plošňák bude například ve formátu PDF, PostScript nebo SVG - u těchto formátů jsou použity fyzické rozměry, ne logické, takže případný čtenář má možnost (ne povinnost) si daný plošňák vytisknout ve skutečných rozměrech, zobrazit si jej na obrazovce v měřítku 1:1 (10cm bude opravdu na obrazovce rovno 10cm) apod. Když si však ten stejný plošňák promítne projektorem na stěnu, získá tak třeba 20x větší obrázek, ale asi se nepředpokládá, že právě tento obrázek převede na plošňák - místo kapesní kalkulačky by tak postavil kus Eniacu :-)
To stejné, i když možná ve skrytější podobě, je s rastrovými obrázky. Když ten plošňák bude zveřejněný ve formátu PNG a v jeho hlavičce bude korektně vyplněno DPI, je možné (a netrvrdím, že každá aplikace to zvládne, to zcela jistě ne) ho zobrazit v měřítku 1:1 oproti originálu, což bude prakticky vždy znamenat přepočítávání původních pixelů na pixely obrazovky či tiskové body tiskárny. Ale v každém případě - opět tam ta informace o rozměrech je, záleží na příjemci informace, jak s ní založí.
Bohužel jsem zatím nepřišel na to, jak v redakčním systému zapsat styl u obrázku, tj. něco na způsob style="width:8cm;height:6cm", tím by to bylo vyřešené pro všechny moderní OS - ty totiž DPI svého grafického režimu povětšinou znají.
26. 7. 2008 9:30
Nový
Re: Paměťové médium pro ZX Microdrive je zobrazeno na následujícím obrázku zhruba ve své skutečné velikosti.
celé vlákno
Na webu je asi nejlépe používat jednotku 'em' - tedy velikosti vyjadřovat ve vztahu k nastavené standardní velikosti písma. Ta asi nejlépe vyjadřuje velikost z pohledu uživatele.
mm (neregistrovaný)
24. 7. 2008 15:36
Nový
ZX Microdrive
celé vlákno
Na ZX Microdrive mam dobre vzpominky. Slouzily mne musim rici docela dobre a spolehlive. Bohuzel i ZX Microdrive cartridge starnou a projevuje se to v jejich pripade daleko hure nez na starych disketach ci MC. Takze dnes je z tech mych jakz takz pouzitelna zhruba ctvrtina, na ostatnich to vypada, ze jsou data nenavratne ztracena a nejdou jiz bohuzel ani znovu naformatovat :-(
24. 7. 2008 15:38
Nový
VideoBackUpSystem
celé vlákno
Ještě bych doplnil - kdosi přišel na to, že by se data dala nahrávat na klasickou VHS videokazetu, říkalo se tomu VideoBackUpSystem. Kapacita byla 1 MB/minutu - na tehdejší dobu absolutně úžasné. Majitelé videa si museli koupit jen nějakou krabičku za cca pět stovek (1996). Používali to Amigisté. Do příchodu CDčka to nemělo konkurenci. Bohužel to prý nebylo moc spolehlivé :-(
Koukám, že nedávno byl nabízen i ne E-bay:
http://cgi.ebay.at/Discount2000-VideoBackupSystem_W0QQitemZ230255351480QQihZ013QQcategoryZ8142QQcmdZViewItem
Koukám, že nedávno byl nabízen i ne E-bay:
http://cgi.ebay.at/Discount2000-VideoBackupSystem_W0QQitemZ230255351480QQihZ013QQcategoryZ8142QQcmdZViewItem
Tom (neregistrovaný)
24. 7. 2008 16:04
Nový
Re: VideoBackUpSystem
celé vlákno
To bych teda netvrdil, VBS jsem na Amize pouzival opravdu intenzivne na zalohovani a nikdy zadny problem nebyl, pokud video nezmackalo pasku, takze spolehlivost extremni. Pouzival jsem vyhradne kazety BASF 300min dlouhe, takze na jednu kazetu se veslo cca 350 disket, coz nemelo konkurenci i hodne dlouho po prichodu CD, protoze CD rekordery byly zpocatku velice drahe a nutny SCSI radic rovnez (na Amigu vysla vypalka Yamaha CDR400 tehdy asi na 20 tisic a radic kolem 6), zatimco nejake to video mel doma kazdy, cely VBS se vesel do konektoru pro paralelni port a stal kolem 300-350 Kc. A jelikoz system narozdil od zde uvedenych medii nepracoval se zvukem ale s obrazem, ve vyhode, co se tyce kvality zaznamu a cteni, byly ty systemy, ktere umely prepnout na cernobily obraz (coz umela Amiga i me tehdejsi video JVC)...
na tom eBay je SCART provedeni, ktere by melo byt z principu jeste spolehlivejsi, ja totiz pouzival provedeni s CINCHem (tj. kompozitni signal)...
na tom eBay je SCART provedeni, ktere by melo byt z principu jeste spolehlivejsi, ja totiz pouzival provedeni s CINCHem (tj. kompozitni signal)...
24. 7. 2008 17:58
Nový
MO + Minidisk
celé vlákno
Ještě bych doplnil MO "diskety" - tuším kapacita 320 a poté 640 MB, rozšířilo se to ale spíš v Japonsku.
Pak se údajně používal někde i SONY minidisk - kapacita asi 120 MB.
...a když už jsme u těch disket, co takhle LS120? :-)
Pak se údajně používal někde i SONY minidisk - kapacita asi 120 MB.
...a když už jsme u těch disket, co takhle LS120? :-)
24. 7. 2008 18:27
Nový
Re: MO + Minidisk
celé vlákno
příště :-) v této oblasti je toho opravdu hodně, MO mechaniky budou v samostatném dílu
25. 7. 2008 10:34
Nový
Re: Co FeRam ?
celé vlákno
Asi bude samostatny dil pro tyto specialitky, spolu s bublinkovou pameti apod.
xor (neregistrovaný)
28. 7. 2008 18:46
Nový
Turbo
celé vlákno
Cau, jak funguje Turbo? Byla pouzita jina modulace nebo komprese? Jinak na C-64 ani tolik nevadilo hledani mista podle pocitadla, ale nastavovani cteci hlavy. Malokdo ji mel nastavenou podle kalibracni kazety..
29. 7. 2008 14:39
Nový
Re: Turbo
celé vlákno
Měnilo se tam víc věcí:
1. zaprvé se zvýšila rychlost z cca 600 Bd u původní struktury záznamu na 2000 Bd (a to s sebou neslo i nějaké úpravy v HW, přesněji netuším). Určitě minimálně "Brněnské turbo" bylo kompatibilní se záznamem Spectra, a i přes "Pražskou" úpravu od JR to fungovalo.
2. poté se odstranily zbytečné mezery mezi bloky - Turbo vše nahrávalo v jednom bloku a ne po 128 nebo 256 bytech, jak tomu bylo u standardního záznamu (některé "nekopírovatelné" hry toto dělaly i pro 600 Bd)
3. přidala se hlavička. I když je to divné, tak původní způsob záznamu žádnou hlavičku neměl, takže pokud program (hra) neměla speciální zavaděč, který například po dvou blocích změnil obrazovku/natáhl obrázek, tak vlastně člověk ani moc nevěděl, co nahrává, hlavně když mu někdo mezitím resetoval počítadlo otáček :-)
1. zaprvé se zvýšila rychlost z cca 600 Bd u původní struktury záznamu na 2000 Bd (a to s sebou neslo i nějaké úpravy v HW, přesněji netuším). Určitě minimálně "Brněnské turbo" bylo kompatibilní se záznamem Spectra, a i přes "Pražskou" úpravu od JR to fungovalo.
2. poté se odstranily zbytečné mezery mezi bloky - Turbo vše nahrávalo v jednom bloku a ne po 128 nebo 256 bytech, jak tomu bylo u standardního záznamu (některé "nekopírovatelné" hry toto dělaly i pro 600 Bd)
3. přidala se hlavička. I když je to divné, tak původní způsob záznamu žádnou hlavičku neměl, takže pokud program (hra) neměla speciální zavaděč, který například po dvou blocích změnil obrazovku/natáhl obrázek, tak vlastně člověk ani moc nevěděl, co nahrává, hlavně když mu někdo mezitím resetoval počítadlo otáček :-)

