Stavba PMD85
Jaký to má smysl? Poslední šance…
Začalo to před několika miliardami let, kdy výbuchy supernov vygenerovaly těžší prvky než jen vodík a helium, a jedním z nich byl právě křemík. Vyvrcholilo to před padesáti lety, kdy se za obtížných podmínek podařilo z těchto prvků sestavit první mikroprocesory. Ty nejstarší už nikdo nechce, v lepším případě se někde válejí, v tom horším už byly sešrotovány. Ale jsou pořád funkční a pořád to dokážou „pořádně“ roztočit, stačí jen, aby jim někdo dal poslední šanci.
A tak i já se přidal k altruistické akci „zachraň brouka“ a rozhodl se postavit na bázi procesoru 8085 počítač kompatibilní s PMD85. Mohl bych si ulehčit život a hrát si jen s emulátorem, také bych mohl koncepci PMD vytvořit v emulátoru sestaveného z AVR, RPi nebo udělat návrh v FPGA. Nic z toho by však neukojilo moji polovodičovo-gerontofilní úchylku, protože tady jde o vzkříšení polomrtvého švába, který si zaslouží prohnat žilou čerstvou elektronovo-děrovou krev.
Postavením dokonalého klonu počítače PMD85 bych asi křemíkové vegetaci pomohl nejvíce, ale jednak mám doma všechny původní modely, takže mě to moc nemotivuje, a jednak bych si na to netroufl. Také se dopustím malého rasistického prohřešku a některé části nahradím modernějšími prvky. Abych to ale s modernizací nepřehnal, stanovil jsem si pro podobné akce 3 svatá pravidla:
- procesor musí být původní – žádná emulace, žádné fpga,
- moderní prvek se nesmí podílet na zvýšení výpočetního výkonu – jen má pomoci dosáhnout na novější technologie – VGA/SD/ PS/2 klávesnice, příp. má zjednodušit původní zapojení (např. statická RAM)
- výsledek musí být kompatibilní s nějakou existující platformou – aby nevznikl jen další krám s jednou demonstrační hrou Tetris.
Vlastnosti cílové platformy
| Procesor | 8085 @ 2 MHz |
| RAM | 128 kB |
| Grafika | 288×256 v 8 barvách |
| Čipy | 8255 – paralelní port pro klávesnici 8255 – 2x paralelní port 8253 – časovač 8251 – UART |
| Zvuk | 1 bitový výstup + SAA1099A + YM2413 |
| Úložiště | SDHC karta – emulace magnetofonu |
| Další možnosti připojení | – klávesnice z PMD85 – PS/2 klávesnice a PS/2 myš – CANON 9 – joystick – CANON 25 – VGA – sériové rozhraní pro spojení s vnějším světem |
| Napájení | +5V/1A |
Emulátor eX85
Postupně budu konvergovat upravenou verzi emulátoru ePMD85 tak, aby se dalo pohodlně vyvíjet i pro tuto platformu. Zatím je ke stažení pouze verze, která reflektuje časování instrukcí 8085 (neumí ani utajené instrukce 8085):
S tím emulátorem je to super nápad, to mě nenapadlo. Ušetří to hodně času. Ale myslím, že tam máš někde chybu, protože ta verze s 80C85 Ti běží zhruba o 10,5% rychleji než emulátor od RM-Teamu pro i8080. A to je podle mne moc na to, že by se mělo jednat o rozdíly v délce instrukcí. Pro generování WAIT stavů u 80C85 jsem předběžně uvažoval o vzorkování signálu S1 hodinami ALE (náhrada za D1 vzorkovaný STSTB u i8080). A možná jej ani nebude třeba vzorkovat. Jak jsi ten signál zapisovacího instrukčního cyklu dekódoval Ty?
K rozlišení VGA. Když zvolím rozlišení VGA 1280×1024@60Hz, lze je velice snadno využít pro režim PMD-85. I když tam je vzorkovací bodová frekvence 108MHz, tak ta vůbec není důležitá. Důležitá je doba trvání viditelné části mikrořádku (11,85us), která vydělena 288-ti dává reálnou vzorkovací frekvenci 24,576MHz. To zvládnou i TTL obvody, pravda, pouze pokročilejší rodiny ALS, HC, HCT, atd. Ale důležité je, že 24,576 je celočíselným násobkem 2,048MHz! Takže synchronní chod je zaručen. Ale to už se nebavíme o použití DRAM jako videopamětí. To už bude o statických pamětech s dobou přístupu raději 10..25ns (i ty se dají sehnat v DIL pouzdrech). Nebo mé nedotknutelné skladové 4ks IDT7106 – dvouportové SRAM 16kx8. Ale ty nepůjdou jen tak lehce sehnat. Tam by odpadly i multiplexery adresy. Jinak vycentrování obrazu bych řešil posunem synchronizačních pulsů, ideálně bych to viděl na použití 4-bitových komparátorů 7485 buď s připojením na nějaký port, nebo jednodušeji s DIP přepínači na desce.
Teď jsem si všiml, že ta Tvá verze s 80C85 je zcela nebržděná. Tímto beru předchozí výhradu o rychlosti zpět. Příště musím pozorněji číst..
Já zatím nevím, kolik cyklů to bude mít během brždění. Pro 8080 jsem to všechno odvodil a v emulátoru už mám přímo konstanty (neemuluji střídání signálu VIDEO – toto jsem dělal kdysi v emulátoru psaném v Javě a bylo to zbytečné). Podle toho, jak si to popsal, budeš vkládat WAIT jen během zapisovacích cyklů, takže např. LDA nebude bržděn vůbec?
Já mám Parallax připojený na stejnojmenné signály z 8085 takto:
ALE je tam 2x – protože je to jediný signál, který během resetu není ve stavu vysoké impedance (vážně netuším, co k tomu konstruktéry vedlo). Jak už jsem uváděl, během resetu otočím směr všech signálů a můžu do RAM nahrát obsah monitoru. Signál ALE z Parallaxu musím proto ORovat se signálem z 8085.
Zápis do paměti odhalím signálem IO/M=0 a WR=0. Samozřejmě předtím čekám na změnu signálu ALE, abych zachytil celou adresu. Můžu odchytávat i zápis na I/O (např. toho využiju pro změnu barevného módu) nebo čtení z I/O. Ale protože budu muset odvozovat CS signály a čtecí/zapisovací impulsy pro 8255/8253/8251, tak dojde i na vzorkování S1 – ale to už udělá PLD. I když podle tohoto zdroje to možná ani nebude třeba.
Ty dvouportové paměti jsou žůžo, ale to nebude pro každého. Jak to vyřešíš se čtením atributů ze dvou mikrořádků? To rozlišení 1280×1024 je dobrá volba, obraz z PMD se natáhne téměř ideálně na celou obrazovku. Ale všechno to kolem sesynchronizovat – to bude ohromné množství hradel.
V originálu se podle mne „posouvá“ požadavek na WAIT stav na liché či sudé takty a jen v jedněch splňuje podmínku pro vložení (požadavek spadne do časového okna během T2). Proto je u PMD-85 počet taktů vždy zarovnán na sudý počet. Takže instrukce LDA určitě nějaké WAIT stavy vloží (zbytečně, viz debata na retro.pecina.cz).
S těmi stavy vysoké impedance u stavových signálů opatrně. Mám pocit, že některé signály (S0, S1 nebo IO/M) jsou v nedefinovaném stavu dokonce i během zbytku instrukčního cyklu (proto bych je raději hradloval signálem ALE). Když jsem je nehradloval, kolidovala mi během IN/OUT sběrnice, pokud byly nějaké fyzické IO obvody připojeny.
Další připomínky: kombinace S0+S1+IO/M umožňuje „předvídat“ instrukční cyklus (takty T1 až T5) ale signály /RD a /WR už jsou „pouze“ vybavovací výstupy pro paměti a IO. Takže zmíněná kombinace IO/M a /WR přijde příliš pozdě na detekci instrukčního cyklu. Raději tedy IO/M a S1.
Čtení dvou mikrořádků, nutné pro režim Colorace, bude opravdu časově náročné. A já tento režim budu určitě chtít zahrnout do „základní sestavy“. Takže buď rychlá asynchronní SRAM 61512 (osobně mám, úzké pouzdro DIL32, 64kx8, cca 20ns) a opravdu 4x čtení na dva takty CPU nebo využít zmíněný systém SAPI AND1Z, kde CPU bude mít svou paměť a videoprocesor taky. Videoprocesor si bude mimo čas přístupu do VRAM scanovat sběrnici a LATCHovat data (adresa+vlastní data) do pomocných záchytných registrů sběrnice, a v neaktivním čase je bude opakovaně klopit do videoram. Pokud budou oba systémy synchronní (VCPU může jet na celočíselném násobku frekvence CPU), pak opakovaný zápis do videoram VCPU nebude na škodu, neboť se tam budou opakovaně klopit poslední (a platná) data.
Jinak využití obrazovky vychází horizontálně kolem 96-97% a to se dorovná nastavením obrazovky. Vertikální pokrytí je samozřejmě 100% a je sudým násobkem 256, což je dobré pro simulaci prokládaného řádkování – ten efekt stojí za to.
Pánové, Pánové, nezbývá mi než tkeskat, pěkně jste to rozjeli, není-liž pravda? 👏👌👍✌
V tomto případě mi asi nezbývá zatím jen “ čumět na drát “ , páč většina z těchto věcí být pro mě více méně jen “ španělská “ village …
Ať se dílo daří 😆😉
Hmm. Tak smůla. Rozbor časování hned první mnou zvolené instrukce (MOV reg,reg) ukázal, že zatímco i8080 v podmínkách PMD-85 jej zvládne za 6T, tak i8085 to stihne při stejném brzdicím mechanismu za 4T. A tím je zbytečné testovat dál. Takže můj předpoklad, že rozdíly v délkách instrukcí se vkládáním WAIT stavů setřou, je mylný. Spíše naopak. U instrukcí s lichým počtem taktů se délky zřejmě srovnají, u instrukcí se sudým počtem zřejmě budou na i8085 o 2T kratší. Mimochodem, když jsem si po čase přečetl tady Zdeňkův rozbor časování instrukcí CPU u PMD-85, tak jsem zjistil, že Zdeněk to má zmáknuté na takt přesně. A se závěry jeho článku na téma „Časování instrukcí..“ se plně ztotožňuji – alespoň na úrovni mých teoretických propočtů.
Takže jak dál? Použít i8080A se všemi jeho vadami, které jsou zároveň tím, co dělá i8080A intel osmdesát-osmdesátkou? Nebo se pokoušet nějakým algoritmem natahovat instrukce i8085? Já osobně bych volil i8080A.. Bo co neni stopro, to mě vždycky s..e!
Já se na to koukal, aby mi v tom zase bylo jasno. No a shoduji se s Tvým názorem, že to u 8085 tak lehce sladit nepůjde. Vyštrachal jsem někde rozepsané střídání taktů a vkládání WAIT do jednotlivých instrukcí. Vycházel jsem z katalogového listu, kde jsou rozepsané instrukce, tuším, že podobná tabulka vyšla i v AR a někde jsem ji viděl na Tvých stránkách (možná těch původních). U 8085 mi to chybí, tam by se dopad zpoždění musel změřit.
Kdyby 8080 nemusel mít další 3 napájení a další 2 čipy, byl by to krásný procesor. Když jsem si ho zkoušel zapojit, udělal jsem si pro něj zdroj uvedený zde, chtěl jsem to mít na jedné desce, protože mi už postupně docházejí originální zdroje pro PMD – ze tří mi zbývá poslední funkční, a nechce se mi v té divočině hrabat. Možná tak i u mě dojde časem na verzi s 8080A.
Já těm taktům zas takovou váhu nepřikládám. Myslím, že by to netrápilo ani původní konstruktéry, když u verze 3 snížili takt procesoru. Ani to není tak kritické jak u ZX, kde mám pocit, že u každé repliky/emulátoru se jen řeší, které demo jede dobře, protože se dodrželo časování. A jak už jsem psal, chci si pohrát i s novými instrukcemi a chci to všechno vrazit na jednu 150x100mm desku – takže u mě je volba jasná.
Nojo. Toho jsem si nikdy nevšiml, že má trojková verze mírně odlišnou frekvenci procesoru. Ale vidím to jen v překreslené dokumentaci tuším od EC1045. Máš to potvrzené i jinak, nejlépe pohledem do útrob skutečné trojky? Protože potom by bylo opravdu úplně jedno, jestli sem tam nějaká ta instrukce ujede o dva takty.
Z hlediska obsluhy SD karty se mi u i8085 osvědčilo následující řešení: čtení vstupních dat přes signál SID. Aktivace SD karty přes signál SOD. Clock pro SD kartu se vyrobí zápisem libovolné hodnoty na některý volný port. Výstupní data z CPU do SD pak brát z MSB druhého volného portu (už nevím proč, ale MSB bylo z hlediska SW nejlepší). SD karta je samozřejmě přepnuta do režimu jednobitové komunikace. Takto programově obsloužená SD karta (respektive BIOS) natahoval 4kB program za nižší jednotky sekund. Dostatečně retropomalé, dostatečně rychlejší než MGF 🙂
Mám doma trojkovou verzi, je tam fakt 18 MHz krystal. I bez otevření to je zjistitelné např. porovnáním zvuku.
Co se týká SD karty – chtěl bych udělat spíše emulaci magnetofonové pásky než disketovky. Zvažoval jsem připojení (přes nějaký modernější čip) k 8251. Tak bych mohl odchytávat i pokusy o standartní ukládání. MHB8251A by měla zvládnout snad rychlost 38400Bd, což je taky docela retropomalé. Ty jsi implementoval obsluhu přímo na 8085? Jaký souborový systém to byl a kolik to tak zabralo místa v paměti?
Podpora zápisu a čtení souborů včetně podpory složek byla nějaký můj vlastní hybrid – FAT tabulka s dvoubitovými příznaky pro každý sektor (volno, obsazeno, poškozeno a ještě něco) a od prvního sektoru uložen ROOT. Protože můj Ultralight8085 měl celkem 128kB RAM, bylo těch stínových 64kB rozděleno mezi videoram, permanentně drženou FAT a aktuální DIR. Včetně BIOSu zabrala programová část kolem 8kB, tak tu podporu SD odhaduji hrubě kolem 2-3kB plus datové oblasti. Bohužel to neumělo pracovat s proudy, bylo to blokově orientované a to je zásadně špatně. Dobré pro MONITOR a natažení programu do počítače ale jinak značně omezující. Ale dnes bych šel už do FAT16 nebo FAT32 abych ta uložená data mohl transportovat mezi 8085 a platformou PC.
A k propojení 8251 versus SD: pozor na to, mám dojem že SD karta vyžadovala MSB first, kdežto 8251 asi jede LSB first. Vím, že jsem s tím řešil nějakou nekompatibilitu. Ono sice jde prohodit tabulkou v CPU pořadí bitů, ale bylo tam nějaké ALE.. A možná ještě polarita versus klidová polarita signálu TxC, i když by jej mělo být možné na 8251 „přeparkovat“ stavem BREAK.
Tak asi navážu na to, co jsem si sbastlil na PMD – karta naformátovaná na exFAT, který umožňuje mít cluster dost velký na to, aby pojmul celý soubor. Obsluha je proti klasickému FAT jednodušší, jelikož všechny sektory leží v rámci clusteru za sebou a nemusím to hledat ve FAT tabulce. Mezi 8251 a SD kartou by asi ještě bylo AVR, právě proto, aby transformoval příkazy ze sériové linky na práci s SD kartou a odchytával ty sekvence FF0055 na začátku hlaviček a zahájil tak automatické ukládání na SD kartu. Vyloženě tím cílím na Spindizzy (příp. jakékoliv budoucí hry), kde nejsou hesla pro to, dostat se do vyššího levelu, takže podpora ukládání může být docela spása. S tím AVR už to sice nebude takové originální, ale to není ani samotná SD karta a SPI komunikace jako taková. Ospravedlňující může být, že místo AVR tam může být třeba 8051 a funkce zůstane zachována.
Ale přemýšlel jsem i nad tím přímým připojením k SD kartě (tedy přesněji SDHC). Odchytávat zápisy bych mohl třeba tak, že by se zápisem na 1E vyvolalo přerušení TRAP se současným přepnutí paměťové banky a softwarově bych pak mohl určit, co se odeslalo.
Přímé ukládání toku dat původně pro MGF a nyní na SD kartu jen s odřezáním hlavičky – no já Ti nevím. To už bych raději řešil pomocí modifikovatelného vektoru pro ovladač MGF a podvrhoval tam adresy ovladače SD karty, nebo RAMdisku nebo nativního ROMdisku, taky jsem uvažoval nad BOOTováním ze sériové linky. A jak říkám, všechny ty knihovny udělat tak, aby podporovaly proudy. Paměťová oblast Axxx nemusí stínovat BIOS, tam by se vešlo ovladačů (a direct assembler! – viz debata na OldComp.cz)
… nemáte tam něco pro bývalé IT nádeníky ? ✌😉😆
( … “ výjimka “ podle vzoru námitka, pořad ČT2, Dobré ráno 6.4.2020 8:25 )
[ @tatrakolemsveta2.cz ]
[ http://www.tatrakolemsveta2.cz ]
ČESKÁ expedice TATRA KOLEM SVĚTA #2
Nazdar Zdenále, tak ty prej se prej vyskytuješ nedaleko Libora L.A. ?
Tak to už bychom mohli být 3 do klubu. 😉😎👍
Info o setkání Zdeněk K. a Libor L.A.
https://www.pmd85.cz/?page_id=1178#comment-1041
Jo jo, jsem kousek. Tak až se národ uzdraví, rád se zúčastním podobné seance 🙂 Teď jsou 3 dny volna, tak se asi zase vrhnu na posunutí mých dosavadních projektů… 😛
Na 15.5.2020 se chystám do OSTRAVY a myslel jsem, že bych se třeba opět zastavil u Libora, ale povídal, že by teď potřeboval makat na baráku ( nabízel jsem mu pomoc i v tomto směru )
Taky povídal, že ty si prý z Toho a že tam jezdí na nákupy 😁😉😎
Tak pokud by jsi měl čas a zájem od 15-17.5.2020 mohli bychom udělat družbu zase spolu, co ty na to ?
Koncem týdne mi dorazily DRAM4464 a tak bych v blízké době 🙂 chtěl něco hodit na nepájivé pole a vyzkoušet nějaké to jádro pro videoprocesor. Pokud by sis Zdeňku (maximalne.8u.cz) udělal pár desítek minut na malou konzultaci, velmi bych to uvítal. V podstatě se rozhoduji mezi variantami 8bit Dualport SRAM (max. 4 barvy), 12bit DRAM (Colorace) a 8bit SRAM (opět pouze 4 barvy). No a taky mi došly SAA1099, takže pár koordinačních poznámek ohledně jejich budoucího adresního standardu.
Já jsem si nedávno pustil přednášku p. Kišše, kde vyprávěl, jak z obvodu pro refresh DRAM vytvořil videoprocesor a ten pak (ukazujíc jeho rozměry) někde předváděl a všichni si z toho sedli na zadek. Při té příležitosti mě napadlo, že kdybych stavěl systém s 8080, určitě bych chtěl zachovat původní patentovanou konstrukci, tj. obvod, který v koordinaci s 8080 vyplivuje videodata na sběrnici, ale jen z důvodu vzdání holdu původnímu nápadu. Multiplexování adres bych ale řešil jednodušší konstrukcí (CPLD nebo 2×74590 + 2×74245 s paralelně propojenými výstupy – multiplex by se řešil 3stavem). Proto se mi nejvíce líbí varianta 12bit DRAM. Ale záleží, jaký cíl sis stanovil Ty. Tak dlouho Tě vidím psát o dualport SRAM (pamatuji si to už na starých stránkách k Ultralightu), že dokud si to nepostavíš, nebudeš mít klid 🙂
Adresní standart u SAA1099 už položili bratři Bórikové, tam bych asi nic neměnil, akorát přerušení bych neřešil umělým prodlužováním impulsu, ale postavil to na základě signálu INTA, který se táhne přes celé PMD až do systémového konektoru (možná se ale pletu, ale nějak jsem to kdysi spytlíkoval s jednou 7474 a jednou 7400).
Tak poďme na ten brainstorming…
Nejprve k variantě DRAM:
Když jsem se nedávno díval na zapojení C2717, zjistil jsem, že má signály /RAS a MUX pověšeny přesně tam, kde bych je podle výpočtu čekal. To je přinejmenším dobrá zpráva. Systém 12-bit DRAM ve spojení s 80C85 skýtá jedno úskalí. S tím jsem narazil při pokusech s již zmiňovaným Ultralightem. Buď je třeba pomocí odporů řádově 2k2 „oddělit“ data DRAM od datové sběrnice, nebo zapracovat oddělovač, jehož funkci podle mne u PMD-85 zastává 8228 s přivedeným signálem VIDEO. Protože mě silně děsí různé kondenzátory, pověšené na výstupy 74164, chtěl bych udělat naprosto synchronní generování kaskády RAS/MUX/CAS a ostatně i generování pixelových „hodin“ pro shifter 74166. Nevím sice, jak rychlé DRAMky byly u C2717, mi časování pomocí 74164 krásně vychází pro DRAM 150ns a rychlejší.
Nyní k variantě Dualport SRAM:
Je to super jednoduché řešení, bez multiplexerů, bez složité synchronizace, bez oddělovačů sběrnic, možnost provozu výstupu VGA, atd. Ale kdo další takovou verzi opakovaně postaví? Kdo si někde z čínského skladu objedná IDT7106? Ten obvod je silný atyp, což je ale asi jediný důvod, proč do této varianty nejít. Když to postavím kolem toho obvodu, budu asi jediný, kdo se do této konstrukce pustí. A potom: ty barvy, ty barvy!!! Colorace mě láká, takže misky vah se u mne překlápí na stranu varianty DRAM. Ale je to názor můj. Co ostatní?
U toho SAA1099 mi jde spíše o to, zda v případě nějaké repliky do neoriginálního case (například s klávesnicí na bázi spínačů CHERRY apod.) neudělat uzavřený systém, který bude mít ale vyveden konektor pro myš, joysticky, IMS-2, bude mít integrovaný čip SAA1099 a tím pádem bude jednodušší neúplná adresace. Přeci jen se mi nechce pro každý čip dekódovat 6 a více bitů adresy. To v diskrétních hradlech bude dosti nechutné. Takže SAA1099 by nakonec mohlo být adresováno takto (A7:A0)=“11xx11xx“. U uzavřeného systému by to nikdo nepoznal. A pro myš by zbyla skupina adres „10xx11xx“, zahrnující úplnou adresu 8Ch.
Primární ale vidím rozhodnutí: DRAM versus Dualport SRAM. Něco jako replika versus moderna. Nebo otrocky historické pojetí versus jednoduchost daná vyšší integrací. Nebo: do originální bedny nebo open frame?
Aha, takže nakonec to přeci jen postavíš na 8085, zdálo se mi, že ten nesoulad v taktech Tě odradil…
Moc teď nechápu, proč potřebuješ oddělit data DRAM od datové sběrnice (týká se to těch 4 bitů pro colorace? Tak místo třetí 4464 použít 2x 4146?). Ty kondenzátory se mi taky nelíbí, u 8080 je ale možnost pěkně rozdělit celý takt na 9 ticků, jak takové rozfázování provedeš u 8085? Extra generátor, ze kterého pak bude vycházet i taktovací frekvence pro 8085? Např. základ 24,576MHz => vydělit 8 => 4,096 vstup X1 u 8085; 24,576 pak poslouží pro synchronní automat ke generování RAS/CAS/MUX atd.?
K tomu adresování SAA1099 – nejsem moc fanouškem neúplné adresace. Ostatně pro ni ani nevidím důvod – jeden 3205 (příp. 74138) rozdekóduje 8 čipů s nulovým a7, další 3205 rozdekóduje 8 čipů s jedničkovým a7. Ale v uzavřeném systému – proč ne. Když na to přijde, SAA1099 je jen výstupní a myš jen vstupní, takže tam ani žádná adresa nemusí být (stačí a7 v jedničce + /RD nebo /WR). Já si tam ale budu ještě přidávat jeden zvukový čip YM2413, takže dejme tomu, když ho zavěsím na port CC, nebude se podle Tebou navrženého schématu překrývat s myší a s SAA1099 nebude kolidovat (narozdíl od SAA se z něj dá i číst a detekovat ho) …
Dilema, které řešíš v posledním odstavci, jsou jen o tom, jak to cítíš Ty. Vidím, že myslíš na ostatní („kdo další si takovou verzi opakovaně postaví“), tj. chceš to udělat jednoduché, ale současně aby to bylo atraktivní i pro zapřísáhlé retromaniaky, pro které je SRAM sprosté slovo (ono to i tak trochu zní, že). Když byly funkční stránky nostalcompu, označil orignální zdroj PMD10, vyráběný ve své době, za „hnusnou modernu“, jelikož se jednalo o spínací zdroj – tohle je náročná skupina lidí. Já jsem si to rozsekl už dávno (viz text v článku výše) – stačí mi, když celý systém potáhne původní procesor. Takže u mě vítězí jednoduchost daná vyšší integrací a vrazím tam SRAM a původní čipy 8255/8251/8254. A výsledná konstrukce bude něco jako ZX Spectrum NEXT – jen ve velikosti klávesnice a bez ARM a FPGA.
Tedy postupně:
Oddělení datových vstupů/výstupů DRAM rezistory od datové sběrnice je nutné proto, že když nastane stav WAIT (videocpu přistupuje do RAM), tak nikdo v té chvíli nezakazuje procesoru ani periferním obvodům, aby něco posílaly na datovou sběrnici. A tam mi u Ultralightu vznikaly proudové špičky a docházelo ke kolizi na sběrnici. Mi se to projevovalo pršením v borderu, ale to byla specifická reakce Ultralightu. Sice jsem to detailně netestoval, ale předpokládám, že 8080A má díky 8228 možnost odpojit datovou sběrnici během WAIT (signál VIDEO přivedený na /BUSEN). Ekvivalent u 8085 by byl buď externí oddělovač datové sběrnice nebo obyčejné odpory. Ty jsem u Ultralightu dodatečně zkoušel a v podstatě to řešilo situaci. Asi by šlo laborovat s jejich hodnotou, ale je to cesta.
Taktování systému 8085 bych řešil pro master clock 12,288MHz. Synchronní dělička třemi by dávala vstupní takt 4,096MHz pro CPU 8085, z kterého si CPU vyrobí skutečný takt 2,048MHz (přítomno na výstupu procesoru CLKOUT). Tento CLKOUT jde do datového vstupu 74164 (OSC je na 12,28MHz) s tvarováním na obdélník s plněním 2:6 (někde na 6. výstupu vychází /RAS, dále MUX a další výstup /CAS). Signál /CAS však bude třeba hradlovat pro dekódování RAM/ROM a tak bude zřejmě odvozen od MUX a předstih adresy před /CAS bude dán zpožděním na té dekódovací logice pro /CAS. V podstatě je to velmi podobné řešení jako u již zmíněného C2717. Toto řešení se mi líbí mnohem více než origo PMD-85.
S tím sdílením adres myš versus MIF to zní zajímavě. Tedy že se nekryjí z důvodů READ ONLY/WRITE ONLY.
Ad zvuk: Mimochodem, já mám zase pár kusů YM3812/YM3014. Ale tady bych respektoval fakt, že první standard vytvořili v RM-Teamu a já bych to už netříštil. Ale proti gustu..
Jo, tak ten problém, že WAIT není HOLD a datová sběrnice není odpojená, jsem přehlédl.
Přemýšlím nad tím hradlováním /CAS, myslím, že to není třeba, jelikož obvody 4464 mají vstup /G, tj. vždy může proběhnout kompletní zápis adresy, jen na základě adresy se určí, zda se (při čtení) aktivuje /G u RAM, nebo /OE u ROM. Zápis jde vždy do RAM.
Díky za ten tip s vývodem /G u DRAM4464. Zatím jsem schéma pro ty 4-bitové verze nenavrhoval, ale bude se to hodit. I když to je jen otevření výstupních budičů a tedy řešení jen pro čtení, tak asynchronním hradlováním /W zase mohu blokovat zápis. Tím pádem dojde na řešení, kdy tři po sobě jdoucí vývody 74xx164 budou představovat signály postupně /RAS,MUX,/CAS. Toto řešení mě od začátku láká a vypadá velice kulturně.
Pro výstupní pixelový posuvný registr bych použil 74xx166. Ano, 166 a ne 165. Verze 166 je kompletně synchronní a to by mělo jednoznačně odbourat efekt širších pixelů na pozici LSB.
Svého času jsem přemýšlel nad variantou náhrady 74xx93 za 74xx193 nebo jiný čítač s předvolbou. Ve spojení s možností přerušení od vybraného rozkladového TV řádku by pak šlo dělat různá kouzla vč. hardwarového scrollingu, něco na způsob DISPLAY LISTu z ATARI atd.
Pro náhradu MHB8282 jsem z hlediska proudové zatížitelnosti prozatím našel 74ABT245.
Jo a perlička na závěr. Místo generátoru vteřin U114D/MHA1116 bych dal PCF8583. Dělá se v DIP8, napájení +5V, výstup po resetu 1Hz. Alternativně uvažuji o tom, že bych vyvedl nejpomalejší „kulatý“ signál z rozkladových obvodů obrazu a dodělil jej nějakou malou děličkou TTL. To je druhá možnost.
Mimochodem, pověsil jsem ten příspěvek sem, protože jsme asi vyčerpali hloubku možného zanoření příspěvků.
tak jak Zdenále, děláš něco ?
… nějaké novinky krom COVID-19 ? 😁😎✌️
…. asi ho zabil COVID-19
a nebo ho zase sežralo VR
KDO VÍ ?
Ale houbelec, jen je moc teplo na sezení u kompu… Nějaké posuny mám, ale Libor mi do hlavy nasadil Double Dragona, tak jsem více zkoumal, jak ta arkáda fungovala, trochu ho debugoval v Mame… Prostě tam v hlavě sedí a přes něj nevidím na to ostatní…
A teď si představ, že by ta nádhera běžela na true LSTTL coreIV PMD-85 s 10xDRAM4164 a kvalitní klávesnicí na bázi Cherry nebo Gateron s podporou SAA1099. To by asi bylo maximum, co by si člověk mohl přát. Pak bychom to mohli už zabalit a předat další generaci, která by to dala konečně do muzea. Tak hodně štěstí při rozjímání, a ať je to do vánoc 2021 hotovo! Teď alespoň nějaké malé demo, ať je co předvádět na akcích. Ale pokud Tě mohu trochu ovlivnit, zkus to dostat do 64kB. Ať to jede na skutečném PMD-85.
Zdenale, už je něco na světě ohledně DOUBLE DRAGONA ? 😉✌️😎😁
Něco málo jsem vytvořil, zatím jen skroling s postupným vkládáním dlaždiček, ale dostal jsem se do stavu, kdy to bude lepší asi celé předělat. Původní dlaždice 16×16 nahradím dlaždicemi 18×16, aby se to hezky zarovnalo s formátem obrazu v PMD85, a tak bude i lehčí generování pozadí pro sprity, protože z důvodu velké paměťové náročnosti tentokrát nepoužiju offscreen obrazovku. A proto to odkládám, aby se to v hlavě pěkně rozložilo, a vracím se zase k něčemu jinému rozdělanému…
Ale vypadá to nádherně. Škoda, že jsme tohle na PMD-85 neměli před 35-ti lety. Jako inspiraci pro vyřešení paměťové náročnosti bych nadhodil systém PoP: obrazovka je z makrodlaždic 4 bajty na šířku x 64 bajtů na výšku a jako stínová videoram stačí bufer v zápisníku o velikosti 4×64. Pokud se některá dlaždice změní (svou kresbou nebo průchodem postavy), pak se vykreslí postupně všechny vrstvy do buferu a ten se zkopíruje do videoram. Pokud si myslíš stejně jako já, že to musí být pomalé, tak není. PoP pro PMD-85 přesně takhle vykresluje.
Ano, přesně tak nějak by to mělo pracovat, akorát ty dlaždice budou 18×16 (3 x 16 bajtů), aby se lépe dala převést původní grafika. Samotné postavičky nebudou jeden sprite, ale kolekce několika spritů pevné šířky, protože některé chvaty jsou dost roztahané.
no vidíš, že to jde, když se chce 😁👍 pěkné, pěkné
Taky jak vidím, nachystal jsi novou verzi emulátoru PMD Emulátor v1.7, není-liž pravda ?
Kdy bude tato verze oficiálně ke stažení ? ( popřápadě jako beta )
… mimochodem, objevíš se na oldCOMPu ? 😎✌
Verzi 1.7 nemám, jak vydám novou verzi, automaticky si inkrementuji verzi ve zdrojovém kódu a vše, co upravím, si zaznamenávám. Zatím je tam pouze jedna nepodstatná úprava – prodloužení simulace generování pilotního tónu při nahrávání z pásky. Jedna hra kvůli tomu nejde nahrát, neboť nestihne dekomprimovat logo před načtením dalších dat. No – jsou i jiné emulátory, kde to funguje správně, takže svět neutrpí žádnou újmu, když vydání nové verze pozdržím, až tam bude opravdu něco zásadního.
Na oldComp nedorazím.