OldComp.cz

PMD používá BUS mouse, což je systém ze začátku 80. let, tedy mladší PS/2 myši mu náladu nezkazí. A u klávesnice z neekologických plastů a ocelovými péry v tlačítkách, co mi vydržela od 386 se moc nebojím že mi nevydrží funkční i těch dalších pár desetiletí s PMD než já půjdu do kompostu . Teprve až někdo vezme běžnou sériovou myš a naláme ji úspěšně na přibastlené RS232C ve funkční konfiguraci začne být "problém PS/2" významnější.

Řešením by mohlo být USB Keyface, pak by bylo vystaráno zase na dlouhou dobu. A když bude ve formě samostatné destičky stejně jako to současné, tedy jen se stará vyndá a zacvakne se nová a pojede se dál, nebude nedostupnost PS/2 žádný velký problém - to je výhoda modulárních řešení.

Nějaké tipy na ten DVI/VGA RAMDAC? Trochu se to tu spamuje tak jde o to jaký čip a kolik RAM mu dát viz předchozí stránka.

Protože se zjevně stále pohybujeme ve fázi úvodního brainstormingu, uvedu pár zkušeností ohledně generování výstupního videosignálu. Nativní rozlišení PMD-85 o hodnotě 288x256 lze nafouknout na jakýkoliv rozměr, ovšem jinak to funguje u vodorovného rozměru a jiná pravidla je nutno dodržet pro nafukování v rozměru svislém. Praktické zkušenosti mám s VGA, takže ty uvedu nejdříve. Nejprve je nutno vybrat některý ze standardních režimů VGA (existuje prý nějaký výpočtový model, podle kterého pozdější monitory uměly téměř libovolné rozlišení - no nevím..) a tento zvolený model by měl mít ideálně 256 mikrořádků (neřešitelné) nebo celočíselný násobek či mírně více (768x576, 800x600, 1024x768, 1280x1024, ..) Pokud bude "mírně více", budeme mít větší či menší černý BORDER kolem obrazu nahoře a dole. Platí jednoduchý vztah pro počet pixelů na řádku, dobu viditelné části řádku a bodovou frekvenci: N = f x t. Konkrétně režim 1280x1024@60Hz má viditelnou část řádku 11,85us. Pak bodová frekvence vychází 24,3MHz. Když zvolíme "standardních" 24,576Mhz, dojde sice k nepatrnému zmenšení obrazu ve vodorovném směru (to si monitor vykompenzuje) ale dostali jsme se na celočíselný násobek master oscilátoru celého systému PMD-85. Rekapitulace: master=bodový kmitočet=24,576MHz, vydělením šesti dostaneme 4,096MHz pro i8085 a samotná i8085 si z toho udělá systémový kmitočet 2,048MHz. Bez ohledu na použitý přístup videoprocesoru do videoram bych ovšem zavedl (třebaže zbytečné) zpožďování CPU signálem READY, abychom záměrně ztratili těch cca 15% výkonu a rychlost CPU bude téměř identická s originálem. Vodorovné rozlišení stále zůstává 288pix. A svislý rozklad by každý mikrořádek originálního obrazu opakoval po sobě tolikrát, kolik činí poměr VGA rozlišení ve svislém směru (..x1024) a originálního rozlišení PMD-85 (256) - takže čtyřikrát. Zbytečné nejnižší dva bity adresy svislého rozkladu obrazu by se nevyužívaly, pouze ten vyšší z nich by mohl být zaveden do RAMDAC jako jeden z výběrových signálů barvového registru, aby se dalo simulovat efekt prokládaného řádkování analogové televize, tak jak to mají například kluci v emulátoru PMD-85. Zkoušel jsem to a vypadá to mnohem lépe než 100% pokrytí plochy obrazovky pixely.

No a k DVI - adekvátně výše uvedenému považuji "roztažení" původního obrazu PMD-85 na nějaký "násobný" formát jako řešitelné. Jen s ohledem na vodorovné vzorkování bude muset být i vodorovné rozlišení cílového formátu celočíselným násobkem čísla 288 (počet pixelů na šířku).

Pokud se použije RAMDAC s analogovým výstupem, je citlivý na filtrování napájecího napětí. To není formální věta, to je ověřená zkušenost. Pokud to nebude dobře filtrováno kaskádou kondenzátorů s plně odfiltrovanou šířkou pracovního pásma, objevují se v obraze hlavně svislé (ale i vodorovné) pruhy od rušení z vlastní desky. Když jsem místo RAMDAC používal jednoduché tranzistorové emitorové sledovače, stačilo dát do kolektoru pársetohmové rezistory a pruhy zmizely. Protože ale do napájení RAMDAC nelze odpor dát, asi bych ideálně zkusil filtrovat kombinací LC, nebo jak už jsem říkal, poctivě tam naskládat různé kondy podle jejich rezonanční frekvence tak, aby ideálně snižovaly impedanci napájecího napětí v celém rozsahu pracovních frekvencí. Doporučuji RAMDAC UM70C171 (TR9C1710) - nic jednoduššího jsem prozatím neviděl. Digitální vstupy (barvy, sync, atd.) analogové RGB výstupy, DIL28.

Pro představu: já mám teď v PMD85 Parallax Propeller, a ten mi generuje VGA v rozlišení 800x600 s tím, že obraz PMD85 se promítne ve dvojnásobném zvětšení 576x512 (viz obrázek). Na ten BORDER okolo jsem si zvykl...

Ani jsem neměl nějaké problémy s filtrací napájení nebo rušení, ty asi nastanou, až se něco takového pokusíte zpytlíkovat z diskrétních hradel...


Jo a ještě k tomu brždění procesoru - zrovna větší rychlost procesoru bych bral jako opodstatněnou evoluci.

_________________
http://maximalne.8u.cz

Ad zvýšení rychlosti CPU: já jsem tvor věčně nespokojený a tak jsem u svého Ultralightu 8085 (kopie HW PMD-85 na bázi hradel) neustále vylepšoval rychlost a grafické rozlišení až jsem se dostal na cca 6MHz CPU clock a rozlišení 640x480x16 barev. A víte co? Pocit vítězství se nedostavil. Pořád to byla plečka z éry osmibitů, která neměla ani na Amigu ani na Atari ST, natož na lepší stroje. Zavedlo mě to do slepé uličky, kde jsem si řekl: tudy jsem jít nechtěl. Stejné je to i s memory bankingem. To, co lze realizovat technicky, ještě nemusí dávat existenční smysl. Budu argumentovat opět stejně: když model 4 bude umět rychlost +15%, x2 nebo x4, tak na pokusy jedinců, které to baví, je to OK. Ale standardní aplikace (=vyvíjené hry) nemohou umět několik desítek kombinací hardware a tak budou nadále psány buď jen pro standardní HW nebo pro některou odnož. A z této roztříštěnosti mám obavy.

Ano, ale +15% mi nepřijde až takový výrazný posun, aby se kvůli tomu musel přidávat navíc brzdící hardware. Pokud se hry budou synchronizovat jinak (např. 8251/8253), tak to v podstatě ani neznamená nutnost nějak upravovat sw a to ostatní bude "trochu" rychlejší. Z historie víme, že to není žádná výjimka, např. na Atari 2600 jely hry různě rychle, pokud měly 60Hz nebo 50Hz normu.
A navíc kompatibilitu to nenaruší už vůbec, na rozdíl od zmiňovaného memory bankingu...

_________________
http://maximalne.8u.cz

Ten brzdicí hardware je jen jedno hradlo EXOR (i8085 má na S0 nebo S1 defacto ekvivalent signálu WRITE stavové sběrnice i8080). To by mě nebolelo. Nadřazená synchronizace pomocí UART8251 nebo CTC8253 je opravdu dobré řešení, a hry by se možná daly zpětně upravit. Je to kacířská myšlenka - ale technicky to lze udělat.

A teď jsem už měl napsánu větu "ovšem existuje jedna (jediná) výjimka, kterou znám. A tou je generování hudby na beepru." Jenže: na skutečném PMD-85 nebude vzorkování do zvukové karty 44100Hz takže tam pár procent nehraje roli. A v emulátoru si stejně nabrnkám konfiguraci dle libosti.. Takže, hm.. S tou rychlostí CPU by to asi stálo opravdu za širší rozbor a debatu pro koho, v jakém rozsahu a jak technicky se postavit k regulaci rychlosti. Nutno ovšem vzít do úvahy vazbu na synchronizaci s videoprocesorem. Takže úvahy o navýšení rychlosti CPU budou těsně svázány se změnou struktury videoprocesoru, jinými slovy to vede na řešení pomocí DUALPORT RAM, aby oba procesy mohly být do určité míry asynchronní (ne libovolně ale v určitých násobcích).

Od této chvíle se k otázce rychlosti CPU již nebudu stavět tak striktně, jakkoliv jsem spíše pro zachování technické životnosti platformy a nikoliv pro její akceleraci.

Diskuse se pěkně rozjela, to mám radost.

K tomu nepřivšímu pocitu vítězství - to je silně individuální. Já bych si třeba u PMD na 640x480 a 16 barvičkami chrochtal. . Ano, nebyla by to ani Amiga ani Atari ale bylo by to PMD co má VGA, tedy výrazně menší obtíže s vyvedením signálu ven .

Nějaké brzdící algoritmy bych taky neimplementoval, jednak těch 10-15 % výkonu není tak moc rozdílných, spíš to celé bude příjemně svižnější. A zase za mě - proč ostatním lidem nedat rychlejší režimy, které někomu třeba nic neříkají ale mít je uvnitř by nic nestálo.

To je jako mít vyhřívání sedaček v autě - někdo to nezapne nikdy a někdo rád mačká knoflíky. Kdo totiž programově využije meagasuperrychlý režim, tak by se starší verzí PMD měl stejně smolíka... Ano, dá se argumentovat že má použít jiný počítač ale třeba dotyčný nechce. A díval bych se na to i očima "vlastníků" emulátoru - těch bude radikálně víc než majitelů reálného hardwaru. Jak složité je zaškrtnout rychlost CPU "2x" či "6x" u původního stroje? I dnes můžete psát programy, které na původním PMD nebudou rychlostí použitelné a na emulátoru to prosviští jako z praku. Ano, opět se můžeme bavit nad důvody něco takového dělat ale zase, proč to tak moc osekávat když není nutné to držet osekané. Jeden přepínač problémy se zpětnou kompatibilitou vyřeší. 85-1 a 2 taky už nikdy nespustí RUNNER v CP/M a pláče kvůli tomu někdo? Ne, všichni si to spustí na verzi 2A/3 neboť v emulátoru mají pohodlně k dispozici 64 kB počítač. Stejný postup se bude aplikovat i na model č.4 nebo budete mít rovnou správnou verzi hardware na stole...

Za memory banking se taky budu prát - když máte až 3x rychlejší CPU tak můžete mít větší program a na něj potřebujete větší RAM. Když PP-01 může mít 1MB, tak proč ne mnohem rychlejší počítač? A rozbitá kompatibilita - proč když nebudete lézt z banku 0? Na větší rozlišení by se stejně muselo zavést, VGA v 16 barvách i s PMD přístupem je 308 kB RAM, jinak půl mega... Proto jsem v tom na papíru nakresleném schématu rozdělil paměť na část s dual port a obyč. single port SRAM, kde by byla VideoRAM a "obyčejná" RAM. Jestli to tedy je technicky takto řešitelné .

S tou rychlostí, Martin z RM-Teamu poznal na Manic Minerovi tuším cca 8% rozdílu rychlosti. Ono se to nezdá ale je to vidět. I takto malé hodnoty.

Při čtení posledního článku Czech Human mi ještě přišla na paměť jedna odsledovaná skutečnost. Čísla berte s rezervou, jde o princip a hrubý nástřel. Ale jak jsem postupně zrychloval svůj Ultralight 8085, tak jako minimální použitelná frekvence CPU vychází s ohledem na rychlost tisku a scrollingu hodnota 2MHz CPU/16kB videoram. To už je hodnota, kdy práci nad videoram vykonáváte pomocí instrukcí PUSH/POP, v případě i8085 si lze ještě pomoci instrukcí LHLX/SHLX. Ale jestli si dobře vzpomínám, lze se dostat na rychlost přenosu limitně 14T CPU/bajt. Pod tuto hodnotu už ne, takže z požadovaných dob pro vykonání určitých procesů a objemu přenášených dat a rychlosti přenosu si uděláte obrázek, jak velikou videoram má smysl u osmibitu mít. Podle mne max. 32kB, pokud nebudu mít hardwarový scrolling obrazovky.

Dodatečně doplněno:
Limitní rychlost přenosu dat na PMD-85 je 17T CPU/bajt a vlivem vkládání WAIT stavů je limitní rychlost přenosu snížena na 20T CPU/bajt (20/2048000 => cca 10usec/bajt).

Jo, ja som to onehda spoznal na svojom Kvadrovi, ktory som robil na emulatore a potom prislo krute vytriezvenie, ked som videl na realnom zeleze, ake je to ukrutne lenive. Potom to pan Pecinovsky presne vypocital a objasnil na svojom blogu. V sucasnosti to podla tychto vypoctov nas emulator verne spomaluje na realnu rychlost.

PP-01 ho má... No žerty stranou. Myslím že u cca 3x urychlení je zhruba ekvivalentní 3x12 tedy 36 kB. VideoRAM o velikost 32768 kB bude praktičtější na implementaci, tedy ve finále by mělo dojít i při CPU zpracování dat k malému nárustu výkonu, matematicky 11 % pokud se počet bodů ztrojnásobí. Já si v těch šílených rozlišeních počítal cca 18 až 20 kB, tam by bylo urychlení vyšší...

288x244= celkově 73728 bodů; SYOG+BG 288x242 = 69696 bodů; SUOG 255 x 242 = 61710 bodů. Na 6+2 bity je potřeba 11712 B, 11,4375 kB. Plně kompatibilní režim s PMD 85.

576 x 244 = 140 544 bodů (2x) - CPU bude zvládat na dvojnásobné frekvenci shodně rychle. Na 6+2 bity bude potřeba 23424 B, 22,875 kB. To se pohodlně vejde do RAM a nechává to volný prostor 4 kB na kompatibilitu s PMD 85.

864x 244 = 248 832 bodů (3,375x) - CPU bude na trojnásobné frekvenci vykreslovat s cca 2/3 rychlostí proti PMD 85. Na stejný výkon by bylo potřeba 7,8 MHz... Takže buď výš CPU, nebo nepoužít. Na 6+2 bity bude potřeba 35136 B, 34,313 kB. To je už mimo plánovaných 32 kB RAM a nenechává to volný prostor na kompatibilitu s PMD 85.

Samostatný (textový) režim 480 x 244 = 117120 bodů, na 4 MHz 125% rychlosti PMD 85, na 6 MHz o 88% rychlejší. Na 6+2 bity bude potřeba 19520 B, 19,0625 kB. To se pohodlně vejde do RAM a nechává to volný prostor 4 kB na kompatibilitu s PMD 85.

Samostatný (textový) režim 600 x 244 = 156160 bodů, na 4 MHz 94% PMD 85, na 6 MHz o 41% rychlejší. Na 6+2 bity bude potřeba 24400 B, 22,875 kB. To se pohodlně vejde do RAM a nechává to i 4 kB volný prostor na kompatibilitu s programy PMD 85.


Pokud budeme brát že i8085 má stejnou rychlost zpracování dat, tak na 4 MHz se jedná o 4,9 us a na 6 MHz 3,255 us/bajt.

Na všechny tyto vymoženosti (a kombinace) snad asi nikdy nikdo nepoužil diskrétní hradla. Realizuje se to speciálními obvody (od CRTC 6845 až po VICII nebo TED u Commodore a další..) Momentálně si nedokážu představit kompaktní jednoduchou grafickou jednotku, která by řazením několika jednoduchých bloků dokázala generovat popsané grafické režimy. Zase se oklikou vracíme k základnímu dilematu: neumí tohle například C64 a proto se jmenuje C64 a proto si zájemci o tyto parametry pořizují právě ji?

Ale zkusme to jinak. Ať každý, kdo něco na PMD-85 buď už napsal nebo hodlá napsat, za sebe odpoví na otázky:

1) jaké grafické režimy hodlá podporovat
2) jaká zvuková zařízení hodlá podporovat
3) jaké paměťové modely hodlá podporovat
4) jaké další hry asi tak ještě má smysl převádět na PMD-85 a jaký si to vynutí hardware
5) jaký další hardware (ve smyslu např. FPU, bit blitter, atd.) by použil

Za mne:

ad1) černobílý, RGBM, WGRA(nativní barvy PMD 85-3), původní ColorAce
ad2) beeper, ojediněle MIF-85 (pokud zbude místo)
ad3) zásadně 48kB (v případě krajní nouze 64kB)
ad4) Prince of Persia, Pac Man, série Monty z Commodore, Zorro, ... (jediné požadované rozšíření 64kB RAM)
ad5) tady mě prozatím nic nenapadá, či spíše mi zatím nic nechybělo

Já to sem dal jako seznam možných rozlišení, ne že to všechno tam musí být . Za mě varianta 6845 je ideální kandidát.
Za mě:

1) Mě by stačilo originální rozlišení a jeden textový mód. Díky rychlému CPU nebude problém používat myš, zvuky nebo síťovou komunikaci. Jako bonus by mohl být režim 2x pro jemnější rozlišení když by bylo stránkování RAM. Barvičky bych chtěl v základu klasiku + Colorace a ideálně 16barevné Colorace II co by využilo všech 16 kombinací bitů párového řádku.

2) Momentálně je k dispozici jen piezo a MIF-85, netuším co CPU na 2/3/4/6 MHz zvládne uživit.

3) Originální 64 kB allRAM a konfigurace alespoň s další 32 kB bank 1 pro Video RAM. To by dalo celkem 48+12 kB pro uživatele do textového módu. Osobně bych se nebránil obšlehnout stránkování PP-01 a mít možnost připojit až 1 MB SRAM. Lepší RAM mít než nemít. Hry využívající stránkování by na sebe nenechaly dlouho čekat.

4) Toť otázka, myš je a funguje, joystick je a funguje, klávesnice je a funguje. S 4 nebo 6 MHz CPU, případným FPU se otevírá široké pole působnosti.

5) Já jsem za patici pro FPU Am 9511 ( byť jako nepovinná součást) se symetrickou frekvencí 2/3MHz nebo 1/2 na 4/6MHz a pokud to je možné tak "natáhnout" sběrnici aby se na ni dalo připojit poněkud více zařízení než 1, třeba ve formě přídavného modulu nebo dovnitř (třeba ten MIF na destičce s piny...).

6) A ještě bych přidal jeden bod - co největší modularitu a paticovost. Aby se grafická část dala vyndat a vyměnit, RAM aby se dala vyměnit s nosnou destičkou, Keyface se dal vyndat a vyměnit třeba za USB variantu atd.

Pokut vezmu v potaz pouze sestavy ZPS na SAPI-1 tak máš na výběr při CPU desky (JPR-1, JPR-1A a JPR-1Z), dva alfa numerické displeje (AND-1/AND-1A a AND-1Z s možností stránkovat), jeden monochrom graficky displej s možností stránkovat (DGD-1) dvě DRAM s možností stránkovat (RAM-1/RAM-1A /16-32-48KB/ a RAM-1Z /64KB/) a pokut použiješ simulátor/programátor EPROM (DSE-1) tak si můžeš dynamicky měnit znaky na AND-1Z a taky na DSE-1 je výstup pro stránkování, dva řadiče FDD (RPD-1 a FDC-1). Dvě klávesnice (ANK-1 a C259.11/C262.3) kdy pro hry je teoreticky použitelná jen ANK-1. Tak sestavy ZPS-1 a ZPS-2 mají skoro shodnou sestavu desek ale diametrálně rozdílně programové vybavení. Na sestavách ZPS-3 a ZPS-4 jede CP/M ale tyto sestavy mají společné pouze řadič FDD (RPD-1) a sběrnici (ARB-1) a všechny sestavy ZPS-1 až ZPS-4 v základu mají společné pouze dvě desky a to sběrnici (ARB-1) a desku sériového modemu (DSM-1). Pokut zabrousím mimo ZPS na SAPI-1 tak těch kombinaci co se dá vytvořit, radikálně přibude. I když SAPI-1 přímo z fabriky umožňuje stránkovat a mít dynamicky znakový font tak se to běžně nepoužívalo. Co jsem tím chtěl říct, PMD-85 ve všech mutacích je mezi sebou na drobné odchylky identické v porovnání se SAPI-1. U SAPI-1 je až na pár výjimek úplná adresace periferii ale na PMD-85 víc jak polovinu adresného prostoru zederou jen vnitřní periferie aneb neúplné dekodéry tj. hromada zrcadlících se periferii a na připojování nových periferii už skoro nejsou adresy. Takže se mužem vydat cestou SAPI-1 tj. revoluce nebo cestou PMD-85 tj. evoluce aneb zachovat co největší zpětnou slučitelnost. Ano evoluce v podstatě bude postavit PMD z modernějších IO s doplněním o zavedené moderní doplňky. Pokut jde o video na PMD-85 tak bych zachoval současné rozlišení s ColoAce a možná doplnil režim vyššího rozlišení z C2717. Výstup by mohl být jak na SCART (RGB) tak s pomoci PARALAXu i na VGA. (PARALAX se dělá v DIL 40 takže by celé PMD85-4 mohlo být v THT )

Tak jsem tu svůj názor na věc.

_________________
Ne všichni jsme měli z češtiny za jedna, aneb jsem dyslektik a dysgrafik.

http://www.sapi.cz/

Pokud by bylo PMD 85-4 zpetne kompatibilny alespon s PMD 85-3 tak by to bylo supr,cim menim nazor na to co jsem uvedl v mem vyse uvedenem prispevku. A pardon za něj.

_________________
Amiga - PMD 85
Kafasoft