Uvažovat čistě o rychlosti je trochu zavádějící. V graf. módu 1 s obrazovkou kompatibilní se ZSX (6912 bajtů) je SAM zpomalován přibližně na úrověň Spectra. Jinak má rychlost větší, v závislosti na grafice a konfiguraci paměti. Plných 6 MHz běží však jen v ROM či extra 4 MB paměti.
Vzhledem k potřebě přesunovat data v 16 barevné (4bitové grafice) v 24576 bajtech je i běžná rychlost 4,5 MHz pěkně pomalá… Dodnes se divím, že bez DMA byly vůbec realizovány některé hry. Viz Lemíci. A to ještě autoři nepřišli na všechny triky. Když byli nedávno Lemíci patchováni pro nový DOS (pro IDE a CF karty), bylo ještě vykreslování herní obrazovky urychleno.
Výrobce udělal „jedinou“ zásadní chybu – nestačil dodat počítače včetně disketových jednotek na vánoční trh v r. 1989 – a ty co dodali, měly DOS, který automaticky nebootoval… Pak už bylo na cokoliv pozdě.
Sprajty bych mu osobně nevyčítal, spíše rychlost, větší paletu barev, absenci 16bit procesoru, větší ROM či modularitu ROM systému. To je věc názoru…
všechna pro a některá hlavní proti… mám snad uvedena v těchto článcích:
http://sam.speccy.cz/uvod.html http://cs.wikipedia.org/wiki/Sam_Coupe
Pravda je, ze vyrobce s vyvojem a vyrobou spechal, aby stihl zacit prodavat jeste na vanocnich trzich (klasicka nakupni horecka). To se nepodarilo, navic byly chyby v ROM, ale ten pocitac „zabil“ prave opozdeny vstup na trh.
Dalsi rok uz bylo z hlediska obsazeni nejake vyznamne pozice (ktera by pritahla vyvojare, potom zakazniky atd.) pozde, k dispozici jiz byly pocitace dalsi generace (a lidi z vychodni Evropy, co na Commodory a Atarka nemeli penize, je nemeli ani na puvodni Spectra, takze tam vznikl treba velmi zajimavy Pentagon nebo Scorpion, z cehoz vsak Sinclair nedostal ani libru :-).
Je těžké srovnávat Atari, Commodore a spol. založené na procesoru 6502, 6510 apod. a na druhé straně počítače s procesorem Z80, zvláště tak jednoduché kontrukce jako ZX Spectrum či SAM Coupé, který měl 6 obvodů… To je jako oheň a voda.
Zajímavé je, jak jej hodnotili v době vzniku http://sam.speccy.cz/clanek.html (a odkaz na časopis Crash).
Myslím, že tehdy tábory uživatelů byly skrze jiné periferie i binárky tak oddělené, že SAMa s C64 nikdo nesrovnával.
Zaujalo ma napríklad tých 224 cyklov na riadok pre ZX Spectrum… taká
náhla spomienka že som s tým číslom asi kedysi pracoval, v „monitore“
perfektného českého vývojárskeho nástroja Prometheus, ktorý pri
krokovaní aj rátal takty a snažil som sa aby som to mal v každej vetve ako
násobok štyroch… sranda, spomienka vyvolaná číslom. :-)
Pripomenulo mi to aj program tiež myslím od Proximy, ktorý mal skrolujúci
text v borderi POD obrazom, vyvaľoval som na to oči ako blázon, že ako to
mohli vyčasovať (vraj sa dalo zisťovať či lúč práve kreslí v obraze
alebo v borderi? potom by sa dalo čakať či už je dostatočne dlho mimo).
Takže ja som bol ako mládenec v šoku pod stolom a okoloidúci rodič
nechápal čo na tom vidím. ;-)
he, he :-) na sklonku své spektrácké kariéry jsem po nějakých pokusech upravil loader z kazety tak, že v borderu nad obrazem zobrazoval čas nahrávání nebo jiný údaj. znamenalo to povolit přerušení (volané tuším po vykreslení obrazu na tv, asi to tu bylo zmíněno) a trochu víc pracovat s kalkulačkou ;-)
Da a neda, tak ako to napisal cez prerusenie to podla mna velmi nejde, kedze jednotlive bity pocas nahravania trvali pod 1000 taktov (presne cisla zial neviem, mozno 250/500). Ale viem si predstavit nahravaciu rutinu ktora by mala tak presne casovanie ze by vedela aspon nieco trochu zmysluplne do „border“-u urobit. Ci by z toho mohlo byt pocitadlo, to uz vazne dost pochybujem.
Bezne sa robili pocitadla v pixelovej grafike (prave cez specialnu load rutinu ktora pocas cakania na koncovu hranu signalu stihla updatnut aj grafiku pocitadla a cele to bolo presne rozpocitane na takty aby to nahravalo spravne). Tam nebolo casovanie voci vykreslovaniu take dolezite, stacilo len nacasovat kreslenie voci sledovaniu signalu z magnetofonu.
A isty CYBEXLAB z CR mal myslim v jednom svojom loaderi dokonca nejaku jednoduchu hru. :] Zial uz si nespomeniem na ziadne podrobnosti.
O hre počas loadovania viem, neviem či to nebolo niečo ako Arkanoid…
Ja som vo svojom vrcholnom diele Something Happened 2 mal vlastnú loadovaciu rutinu (s iným časovaním 0/1, keby to človek skúsil kopírovať bežným programom tak bude mať samé nuly), tá robila pásy okrem borderu aj v dvoch riadkoch (16 bodov) cez obraz (práve pomocou rýchlej push inštrukcie), ale to bolo jednoduché, stále to bolo oveľa kratšie ako nula na kazete.
Dá, ale nemá to nic společného s přerušením a nebude to fungovat spolehlivě. Na mém Didaktiku Gama jsem to rozchodil, ale u kamaráda se ZX Spectrum to nefungovalo. U jiného se ZX Spectrum 128K pro změnu ano.
Trik je v tom, že se smyčka pro nahrávací rutinu částečně „rozmotá“. Tam kde jsou podmíněné skoky vzad se napíšou podmíněné skoky dopředu a obě větve se „vyváží“. Je to sice paměťově docela náročné, ale vypadá to jako těžká machrovina :) Nejtěžší bylo správně si spočítat kdy zavolat HALT. Ten byl nutný, protože jinak text náhodně poskakoval o „pixel“ doprava. Ale nesměl se provést moc brzo, protože časová prodleva by rozhodila loader. No a tady jsme u toho, proč to na některém počítači fungovalo a na jiném ne.
Prosím o vysvětlení či o opravu textu: „Vzhledem k tomu, že se časování při vytváření obrazu od původního Spectra odlišovalo, nebylo například možné spustit některé hry, popř. je bylo nutné vhodným způsobem upravit.“.
Nepatrná odlišnost v časování přece nevadí, byla podobná jako u Didaktiku M či ruských klonů, koneckonců v časování se liší i Spectrum+2A či +3.
Která hra nefungovala? To spíše občas probliknul špatně sesynchronizovaný obraz či vykreslovaný „sprajt“.
Další blud autora. Žádná taková hra neexistuje. Časování se používá v demech pro multicolory a zvláštní efekty (použito jen v několika málo hrách), tam použitý klon ZX hraje roli. Že by nějaká hra kvůli časování takovýchto efektů vůbec nepracovala či dokonce nešla spustit na daném klonu je nesmysl.
Na osvitovkach jsem mel na mysli halftone dithering, ktery nahrazuje klasicky (a IMHO uz nepouzivany – pouze pri hlubotisku) autotypicky rastr, navic jeste rozdeleny na barevne slozky (kazdy rastr je pootocen o jiny uhel).
Ono se v nekterych clancich pise, ze pri ditheringu se do obrazku zavadi sum (klasicke dith. algoritmy pro zarizeni s malym rozlisenim, to osvitovky jiste nejsou), ale i halftoning patri mezi ditheringove metody.
Jen pro upřesnění – osvitka žádný dithering nedělá. Ta pouze osvítí médium přesně tím, co mu dodá RIP (raster image procesor), což je jednotka, která se stará o převod obrazu a textu do dat pro osvitku a tedy dělá i dithering. RIP je buď samostatný kus hardwaru (např. EFI Fiery), nebo nyní už téměř výhradně software (Harlequin, EFI Best).
.
A v tisku (myšleno ofsetovém) se jednak používá zmíněný autotypický rastr, ale také rastr stochastický, který více odpovídá klasické představě ditheringu pomocí šumu. Stochastický rastr dokáže poskytout větší barevnou hloubku, ale je náročnější na sladění všech částí procesu.
.
Stochastický rastr je ale přesto velmi snadno k vidění – využívají ho inkoustové tiskárny. A pochopitelně mají svůj RIP – buď zabudovaný, nebo řešený formou ovladače. Koneckonců RIP je součást každé tiskárny kromě čistě znakových – ať už to je obvod nebo jen ovladač.
.
.
P.S.: jsem zvědav, kdy redakce něco podnikne s formou diskusí. Sledování nových příspěvků je stále nepoužitelné. Už zde diskuse prakticky nevyužívám a kvalita článků je dlouhodobě klesající. Ach jo. :(
Presne tak. RIP je dnes temer vyhradne v podobe klasicke softwarove aplikace instalovane na WIN/MAC. Vystupni rozseparovane bitmapy (tiff) se pak posílají do PC se softwarem obshlujici zarizeni CTP (computer to plate), kde se z nich pomoci laseroveho osvitu vytvori jednotlive kovolisty pro ofsetovy tisk. Tudiz odpada meziproces osvitu filmu a jeho nasledne prekopirovani na kovolisty, cimz se setri cas a zvysuje kvalita (ostrost) tiskoveho bodu. Klasicke filmove osvitky se uz pomalu stavaji minulosti… Mimochodem softwarovy RIP jsme u nas pouzivali uz v roce 1997 na pentiu 90MHZ, 64 MB RAM, WIN NT…
Diky za info. Asi uz starnu :-), pamatuji jeste, ze jsme nosili do osvitky klasicke PostScripty a napjate cekali, co vlastne po rozrastrovani a osvitu vyleze :-), bylo to totiz docela drahe a nastaveni PS vystupu pro osvitku byla, co si pamatuju, docela magie.
Nakonec nejlepe vychazely veci z TeXu, tam se veskere rastrovani delalo jeste v DVI ovladaci, takze vysledkem vlastne byly take bitmapy (pismenka v bitmape, ktera odpovidala rozliseni osvitky, tehdy neco pres 2000 DPI), akorat obalene nekolika PS prikazy, ktere ty bitmapy spravne umistily na medium.
ale urcite to bylo uz v dobe, kdy byla Pentia bezne k dostani, zadna novinka
Tak to zcela určitě ne. Hlubotisk je konkrétní technikou tisku z hloubky, zatímco ofset je konkrétní technikou tisku z plochy. A tisk z plochy se od tisku z hloubky diametrálně liší (mnohem více, než se od sebe liší tisk z výšky a tisk z plochy). Při ofsetu se dá tónování jednou barvou ovlivnit jen jedinou věcí – plochou zrna (v praxi obyčejně zarovnaného do pravidelného rastru). Při hlubotisku se jednobarevné tónování ovlivňuje dvěma parametry – plochou zrna (jež obvykle není v žádném rastru) a hloubkou zrna, jež ovlivňuje plošnou hustotu barvy přenášené na papír a tedy i její výsledný odstín, což je efekt u ofsetu nebo knihtisku naprosto nemyslitelný. Vizuální efekt hlubotisku je shodný s fotografií – kde opět zrno není v rastru a může mít různé odstíny, dané délkou a intenzitou exposice – a právě to z hlubotisku dělá supr čupr techniku pro extra kvalitní reprodukce – jsou to vlastně přesné kopie analogových fotografií.
Nevim, ale matne si vzpominam ze 68000 mela vnitrni sbernice 16tibitove. Pouze registry byly 32 bitove a mikrokod se staral aby budil dojem 32bitoveho stroje. Takze napriklad 32bitove scitani se v 16tibitove ALU delalo nadvakrat. Opravdu 32bitova byla az 68020. Ovsem nevim jestli 68008 byla uvnitr 8mibitova, nebo to byla jen 68000 s externi 8mibitovou sbernici.
Jinak pekny clanek.
Z80 rozhodně není 16 bitový a to právě proto, že 16 bitpové jsou tam jenom ty části týkající se adresování paměti. Logicky, se čtvrtkilem paměti by se nedalo skoro nic dělat. Obobně bys pak mohl tvrdit, že 286 nebo zmíněný 68000 není ani 16bitový CPU, protože naadresuje řádově megabajty paměti namísto 64kB.
Já to vidím takhle. Pokud daný procesor má 32bitové registry, 32bitový SP a PC (bez ohledu na to, kolik bitů je reálně vyvedeno z pouzdra v podobě sběrnice a tedy kolik můžu aktuálně osadit RAMěti), tak je to plně 32 bitový procesor i když z důvodu ceny nebo čehokoliv jiného má sběrnici ošizenou. když ho totiž vezmu (nebo nějakého nástupce), tak k němu opravdu ty přímo adresovatelné 4GB připojím, datovou sběrnici si můžu udělat třeba tříkanálovu DDR (to už jsem na X násobku 32 bitů) a přesto se z hlediska programátora a programu naprosto nic nezmění. Kromě rychlosti samozřejmě.
No ale vzdyt to tu BLEK pise ze podle tyhle definice je Z80 16tibitova, protoze nejen adresovani ale i aritmetika se da delat na 16tibitech jednou instrukci (sice ma omezeni na zdrojovy a cilovy registry, ale to zas jina vec).
Nebo jinak. Kdybych vzal Z80tku, pripojil k ni ROMku nejakou malou RAMku a porty abych mel vic ‚nozicek‘, do ROMky dal program kterej bude emulovat 68000 a cely to integroval na jeden chip tak ze by to bylo kompatibilni s 68000 (jenom o hodne pomalejsi), co by to bylo? 8, 16 nebo 32 bitovy procesor?
Mozna by bylo lepsi to rozlisovat podle sirky operandu, ktere jdou do ALU a podle sirky interni sbernice (ale pravda, tyto dva udaje se muzou lisit). Treba secitani, i kdyz nektere osmibitove CPU mely instrukce pro soucet 16bitovych cisel, se vetsinou provadelo nadvakrat – nizsi bajt, vyssi bajt.
U Z80 ma interni datova sbernice sirku 8 bitu, interni adresova sbernice (po ktere krome adres putuji o obsahy SP, PC, IX apod.) ma bitu 16, ale ALU je pouze osmibitova – na vstupu jsou 2 osmibitove hodnoty + C, na vystupu 8 bitu + stavy (C,Z,…)
On se Z80 také někdy označoval jako 8/16 bitový, právě díky těm
aritmetickým instrukcím počítajícím s „dvouregistry“, jenže v tom
označování xbitovosti procesorů je tradičně pěkný zmatek, protože
někdo to označuje právě podle registrů, někdo podle šířky datové
sběrnice, tedy té vnější, ještě jsem viděl nějaký jiný způsob, ale
tak hrozný že si ho ani nepamatuji… :-D
Takže podle datové sběrnice, 8088, ač s šestnáctibitovým vnitřkem
z 8086, byl jen osmibitový (to spáchali aby k němu šly připojit
levnější osmibitové čipy), stejně tak dvaatřicetibitový 386SX byl
z tohohle pohledu jen šestnáctibitový.
S tím adresováním je to blbost, protože třeba skutečně osmibitový
8008 uměl adresovat jen 16KB, takže by měl být podle registru PC
čtrnáctibitový? Navíc tam jde především o množství najednou
přenášených dat, adresování paměti je jiná kapitola.
Nejjednodušší by bylo označování právě podle šířky pracovních
registrů, hlavně toho akumulátoru, ale tam to komplikuje třeba zrovna ta
68000. Pak bych mohl říct že Amiga 500 je šestnáctibitový
mikropočítač s dvaatřicetibitovým procesorem 8-O Takže takhle to asi
také nepůjde.
V poslední kapitole je drobná nepřensot týkající se hry International Karate. Na obárzku s verzí hry pro C64 je ve skutečenosti hra International Karate plus, což je graficky dost podstatně vylepšené pokračování této hry. Původní IK vypadá na Atari XL/XE i C64 graficky prakticky identicky. Obdobně IK+ existuje i ve verzi pro Atari a vypadá opět prakticky identicky.
Jo ZX-Spektrum, pamatuju jak jsme na to delali reklamni software. Vykradli jsme
rutinu pro zobrazovani zoomovaneho textu z te demonstracni kazety horizont a
ovladalo se to joystikem a melo to i cheat.
Nejvice softu pro 8mibity jsme delali na C64. Moc toho ale nebylo era 8mi bitu
skoncila ponekud brzy (do 1992) a ATARI ST nevydrzelo o moc let dele. Zakazky
na amigu jsme nemeli. Na ST jsme delali hudebni soft a textak.
Ty novy diskuze jsou hrozny, jediny zpusob jak nacpat mezeru do textu je
<p><br>
Už se to tu diskutovalo. Nejpravděpodobnější teorie je, zjednodušení rutin malující text na obrazovce (protože navzdory grafického výstupu si myslím, že hlavní tíha byla stále na textu). Přechod na další mikrořádku byl prováděn jednoduše tak, že se inkrementovala horní půlka 16 bitového registru. To znamená připočíst 256 bajtů. A právě jedna třetinka obrazovky má přesně 256 znaků, čili 8×32 = 256. Kdyby to bylo po řádcích, muselo by se připočítat 32, kdyby mikrořádky následovali až po řádcích, bylo by to 768. To jsou všechno čísla, jejich přičítání zabralo na Z80 víc taktů a víc registrů, než jednoduché přičítání jedničky k horní půlce adresového registru.
Navíc, současně se zobrazením znaku se musel nastavit příslušný atribut. Po nakreslení znaku stačilo už jen vyšší půlku adresy posunou 3× vpravo a odečíst jedničku. Výsledkem byla adresa v atributové oblasti (po přičtení čísla 16384, které se dá realizovat i osmibitově v horní půlce adresového registru)
Něco o tom tu bylo také minule,
já si vzpomínám že v BASICu to bylo s grafikou ještě divočejší,
protože zatímco „první znak“ začínal vlevo nahoře, tak „první bod
obrazovky“ byl vlevo dole :-D Nejlepší způsob by asi byl nahlédnou to
výpisu ROM, na netu se vyskytuje anglicky i česky v opravdu velkém množství míst. Doporučuji tu
poslední.
Když pomineme maximální jednoduchost a rychlost rutin při zachování
spousty funkcí, a že jich tam bylo, tak hlavním důvodem pro použití tak
(zdánlivě) nelogického uspořádání obrazovky byla především cena, ono
by to Spectrum samozřejmě šlo udělat jinak – lépe(?), ale stálo by
potom skoro tolik co C64! Tenhle
kousek kódu (15 instrukcí) se stará o vykreslení znaku, pak se ještě
nastavují atributy, to mi připomnělo že kromě osmi standardních barev
(0–7) existovaly ještě dvě další: 8 – transparentní, a 9 –
kontrastní. Vzpomenete si ještě někdo, k čemu byly dobré?
Transparentní a kontrastní? Neznám. Jinak já měl barev 15: 0. Černá
A od barev 1 až 7 ještě verze se zvýšeným jasem (bright). Existovaly klony ZX Spectra, které měly barev 16 – černá se zvýšeným jasem vypadala jinak než „obyčejná“. S čímž ovšem většina grafiků nepočítala a podle toho obrázky při zobrazení vypadaly :-)
Ony tyhle dvě barvy byly tak trochu tajné, na klávesnici nebyly vypsané a
třeba v návodu Didaktiku Gama je odbyli jednou větou. I když on celý ten
návod byl hóóódně stručný, o to víc jsem si vyhrál při
experimentování :-)
O té „světle černé“ jsem něco četl, ale nepamatuji si, kde se to
vyskytovalo. Nemělo to zrovna to Mistrum z AR? Mě spíš docela štve, že
eMko i Kompakt mi na barevné televizi jedou jen černobíle, jak přes anténu
tak i přes Video :-(
Transparentni barva znamenala, ze příslušná barevná informace se zachovala, tedy nepřepsala se. Jinými slovy, pokud se psalo někam, kde bylo modre pozadi, tak pakliže člověk nastavil PAPER 8, zůstalo tam modré pozadí. Pokud zrovna nedal zároveň INK 8, způsobilo to, že se měnila jen barva inku
Transparentni se musel kombinovat s druhou barvou. Pokud dal člověk INK 9, pak barva popředí byla bílá, pokud barva pozadí byla tmavá, a naopak. Podobně se to dalo udělat s PAPER 9, který se pak nastavoval podle popředí.
Opravte mne, pokud říkám něco blbě. Už si nepamatuju, jak se řešilo zachování blikání, či brightu
Říkáte to správně, transparentní prostě atributy neměnila, zůstaly
u každého přepsaného znaku tak, jak byly po předchozím tisku. Kontrastní
byla ještě zajímavější, pro barvy 0–3 byla bílá, pro 4–7 černá,
když díky (zase zdánlivě podivnému) seřazení barev na Spectru stačilo
testovat jediný bit… Mělo to jedinou výjimku, pod kontrastním INKem se
kontrastní PAPER ignoroval. Ilustrační foto, kde jsou
trochu vidět i atributy a současné použití grafiky a textu.
FLASH a BRIGHT mohly být 0, 1 nebo 8, se stejnou funkcí jako u těch barev,
kdy transparentní neměnily předchozí nastavení.
Ještě doplnění k té grafice, i „kreslící“ obrazovka měla v BASICu
jen 22 řádky, poslední dva byly tzv. dialogové, třeba pro INPUT, takže
použitelný rozsah obrazovky měl jen 256×176 bodů.
Na ZX spectrum nebylo až tak podivné řazení barev. Používalo se řazení GRB
G R B
0 0 0 – cerna
0 0 1 – blue
0 1 0 – red
0 1 1 – magenta
1 0 0 – green
1 0 1 – cyan
1 1 0 – yellow
1 1 1 – white
Světlejší barvy jsou víceméně ty, co obsahují zelenou složku (což zní
logicky)
Libi se mi, ze na stare technologie jsou v clanku pouzity moderni pojmy, napr. framebuffer… Na druhou stranu je tady opakovana stara nepresnost „Textově-grafický režim 512×192 pixelů (znakově cca 85 znaků na 24 řádků)…“
Je to obyčejná grafika 5121922, podobne jako 2561924 Znaku udelam v teto grafice nejcitelneji 6424, ale take treba 8519 nebo prtavych 128*32.
Omlouvam se za zmatky. Je jasne, ze se jedna o klasicky bitmapovy rezim (jak je u speccy-like pocitacu obvykle, ma to sve vyhody i zapory). Mel jsem tim na mysli to, ze je urcen hlavne pro zobrazeni textu a to jeste pri pouziti na monitoru, protoze 512 pixelu na radek bezne televize nezobrazi.
To cislo 85 je vysledek 512/6 (pet pixelu na sirku znaku+1 pixel mezera), to je jeste na hranici citelnosti a predevsim dostaneme „profi textovy rezim“ 80 znaku na radek.
To „profi“ dneska vypada smesne, ale pred cca 20–25 lety se terminaly nebo pocitace, ktere mely 80×24 nebo 80×25 povazovaly za profi zarizeni, zatimco osmibitaky s 32/40/64 ne (mimochodem jeste nedavno jsem videl Atari ST v monochromatickem rezimu, ktere bylo pouzito prave jako terminal k nejakemu Unixovemu stroji).
jiste taky je to „Color Personal Computer“ a ne nejaky „Color Home Computer“ :-) Ale to spis 664.
Jinak presne toto rozliseni (a velikost framebufferu, 16kB) mela i „profi“ karta CGA, coz tedy v porovnani s STckem a hlavne Amigou byt docela vysmech. Jestli se nemylim, tak CPC pouzival stejny typ Motoroly jako CGA a MDA.
Jsem si teď vzpoměl na jeden bastl, co vyráběl muj otec. Bylo to světelné pero. Nikdy to nedodělal, ale teprve po delší době jsem pochopil, jak to mělo fungovat (a obávám se, že otec to nedostavěl, protože to až tak moc nepochopil … vyráběl to podle návodu tuším v Amaterském Rádiu).
Světelné pero bylo zařízení jako myš akorát se ukazovalo na obrazovku, jakoby dnešním stylusem. Snad to nemusím dál popisovat.
Princip byl jednoduchý. Jednoduchy KO se připojit přes další obvody ke sběrnici vyvedné vzadu na ZX Spectrum. Prográmek neustále sledoval jednu bránu. Světelné pero obsahovalo fototranzistor, který se sepnul, když na obrazovce šel kolem paprsek. Podle počtu cyklů od počátku kreslení obrazovky (synchronizace byla s přerušením, nebo s instrukcí HALT) se přes kalibrační tabulku odvodila poloha pera. Škoda, že jsme to tehdy na ZX Spectrum nerozběhali, před příchodem myši by to byla dobrá hračka.
Po tom jsem tenkrát strašně toužil, používali to také v nějaké
televizní soutěži. Nedávno jsem ho pro Spectrum sehnal, ale bohužel bez
software, takže ani netuším jestli je ještě funkční.
V microsoftích BASICích byl příkaz ON PEN, který se světelným perem měl
pracovat, po stisknutí tlačítka na peru vracel jeho pozici na obrazovce.
Akorát že pero k PC jsem nikdy ani neviděl a MS se nějak nedopracoval
k tomu, aby zavedl také příkaz ON MOUSE, který by pro to moje hraní byl
rozhodně užitečnější :-D Naštěstí to v QBasicu šlo řešit podobně
jako u toho Spectra, vložením strojového kódu do řetězcové proměnné a
jeho spouštěním, ten se pak staral o komunikaci s ovladačem myši.
Zdarily emulator pocitace SAM Coupe, pro mnoho modernich OS vcetne Linuxu:
http://www.simcoupe.org/