Enterprise Forever
:HUN => Hardver => Topic started by: Zozosoft on 2013.May.24. 15:16:52
-
Ja, vagy az altalam mindig elokerulo dolog, hogy gyorsabb Z80 clone kene ami azonos orajelen is tobbet tud. Egy kis orajel turbozassal egyutt az mar brutalis lehetne :)
[attach=1]
[attach=2]
-
Ez a Z180? Az mennyire teljesit jobban? EXOS2.4 sebesseg teszt btw mit szol hozza, maskepp kene szamolni? :)
Es ha mar EXOS2.4: ajanlhato mar EPROM-ba egetesre es hasznalatra, vagy aze' inkabb ne? :) Mondjuk emulatoron nekem nem volt vele gondom, pedig az van.
-
Ez a Z180? Az mennyire teljesit jobban?
Erről csináltam már egyszer táblázatot.
EXOS2.4 sebesseg teszt btw mit szol hozza, maskepp kene szamolni? :)
Igen, majd meg kell irni ehhez is a programot :-)
-
Z180 ügyben Bruce kollégával már hetek óta törjük a fejünket :-)
Meglepő módon ezzel a drótgubanccal elindul :-)
A fő probléma az, hogy a Z180 elosztja kettővel a bemenő órajelet :evil:
Vagyis alap EP-ben a 8MHz-es rendszerórajelből csinál 4MHz-es CPU órajelet a Nick, amit a Z180 tovább oszt, így végül 2MHz-en fut a CPU mag... nem az igazi :oops:
Itt jött az, hogy legyen 16MHz-es rendszerórajel (ez az ami anno nem sikerült). Ennek a mellékterméke lett a 8MHz-es Z80, amit aztán 10MHz-re is sikerült növelni. Így kiderült, hogy az EP alaplap remekül elviseli ezt a turbózást.
Kipróbáltam a 16MHz-es rendszerórajellel a Z180-at, ami így akkor 4MHz-es lesz, és primán fut mindaddig, amíg nem téved a Nick felségterületére...
A Nick által megvariált órajel megbolondítja a Z180 órajelosztó részét, amitől egy-egy videó hozzáférés után jó adag kb 0.5MHz-es szakasz kerül a CPU mag órajelébe...
Magyarán szólva bazi lassú :evil: az első alapgépes próbálkozásánál (azaz 2MHz-es CPU plusz a videó lassításos kavarodás) szépen látszott pixel sorról pixel sorra, ahogy rajzolta ki az ENTERPRISE felírat betűit :oops:
Annál a bizonyos szuper EP-nél valahogy megoldották ezt. Vajon hogyan?
Na ezen törjük a fejünket...
Ezért kezdtem el méregetni a videó hozzáférések jeleit.
Az már csak egy apróbb probléma, hogy EXOS 2.4 nem indul el Z180-on, csak a 2.1... de ez majd akkor jön, ha már a sebességet sikerült megoldani.
-
Dualport SRAM-ot videoram-nak aztan le van tojva, CPU mehet ezerrel ha VRAM ha nem az adott terulet :) Mondjuk ennek egy hatranya lenne, hogy a spec idozitest hasznalo programok (szamitva arra, hogy videoram eseten lassabb a memoriaeleres, stb) lehet nem viselnek jol. De amugy szep lenne, felteve, ha letezik 64K legalabb dualportos kivetelben SRAM vagy akar DRAM is. A mem tobbi resze lehet sima SRAM is. Apro bokkeno hogy ez elmelet, eletemben nem lattam dual port memoriat "eloben" hogy az mennyire ugy mukodik, ahogy en elkepzelem :) Van dual meg "two" port memoria is (ha jol remlik) az egyiknel szabadon hasznalhato r/w celjara mindket port, kvazi aszinkron modon is, de a masiknal az egyik az read-only a masik meg write-only. Meg ez utobbi se lenne rossz, ha felteszzuk hogy mondjuk 512K "normal" SRAM ul a cimtartomany vegen, es abbol az utso 64K-ra a CPU irasnal megkapja az adatot a 64K dual/two portos cuccos is. Ha a CPU olvas, mindig a "normal" SRAM-bol teszi. A Nick meg a spec 64K-nk masik portjarol csak olvas nyilvan, igy eleve garantalt hogy a vram fele az egyik port az write-only a masik meg read-only. Max azert bekapcsolaskor nem art teleirni az utolso 4 szegmenst h tutira ugyanaz legyen a ket memoriaban :)
Bruce kollegarol regen nem olvastam, epp akartam kerdezni, hogy meg "koztunk" van-e :)
-
És tudsz értelmes használható dualportos RAM-ot amit be is lehet szerezni?
Amit én találtam, ott soros 1 bites a második port, amivel nem megyünk semmire.
Olvasás gyorsítás "shadow RAM"-mal, az könnyű, csak a VRAM jelet kell megbuherálni, hogy csak írásnál szólunk a Nick-nek. Ez tervben is van :-)
-
És tudsz értelmes használható dualportos RAM-ot amit be is lehet szerezni?
Amit én találtam, ott soros 1 bites a második port, amivel nem megyünk semmire.
Abban biztam pont, hogy te pl tudsz, en beszerzesben nem vagyok tul jo :) De most vissza az EP javitasi kiserleteimhez ... Es en megy nagy naivan EP-PC serial kapcsolati kiserletet terveztem be ...
-
CPU típust már felismeri :-) Sebesség mérést még fejleszteni kell, persze majd ha sikerült normális tempóra bírni a Z180-at :oops:
[attachimg=1]
-
Honnan olvassa ki a szoftver a CPU típust?
-
Honnan olvassa ki a szoftver a CPU típust?
Kipróbálja a Z180 új szorzás utasítását. Ha sikerül akkor Z180 ha nem akkor Z80.
-
Zozo, nem azt mondtad, hogy Z180-al valami nem megy? Nem a lassulasra gondolok, hanem vmi olyasmi remlik, hogy vmelyik EXOS verzio hasal el rajta, vagy hasonlo?
-
Zozo, nem azt mondtad, hogy Z180-al valami nem megy? Nem a lassulasra gondolok, hanem vmi olyasmi remlik, hogy vmelyik EXOS verzio hasal el rajta, vagy hasonlo?
A 2.4 tesztje nem indult el :oops: lecseréltem az összes nem dokumentált Z80 utasítást, most már megy :-)
Meg inicializálja is Z180-at, letiltja a belső Wait State generátorát. Ez hibásan volt a jelenleg letölthető Z180 doksiban, az ábráknál azt írták, hogy ezek a bitek 0-ák lesznek inicializálásnál (azaz nincs várakozás), a szövegből derült ki, hogy valójában 1-ek (azaz 3 ws minden memóriaműveletnél). Ezért volt az első próbálkozásoknál borzalmasan lassú. Érdekes, neten található régebbi doksikban még jó volt az ábra.
Inicializálásnál át lesz pakolva a Z180 belső I/O portjai a 40-7Fh címekre, hogy ne akadjon össze az EXDOS-sal. (Ott a Spectrum emu-val akad össze, majd azt átpakolom máshova.)
-
A 2.4 tesztje nem indult el :oops: lecseréltem az összes nem dokumentált Z80 utasítást, most már megy :-)
Meg inicializálja is Z180-at, letiltja a belső Wait State generátorát. Ez hibásan volt a jelenleg letölthető Z180 doksiban, az ábráknál azt írták, hogy ezek a bitek 0-ák lesznek inicializálásnál (azaz nincs várakozás), a szövegből derült ki, hogy valójában 1-ek (azaz 3 ws minden memóriaműveletnél). Ezért volt az első próbálkozásoknál borzalmasan lassú. Érdekes, neten található régebbi doksikban még jó volt az ábra.
Inicializálásnál át lesz pakolva a Z180 belső I/O portjai a 40-7Fh címekre, hogy ne akadjon össze az EXDOS-sal. (Ott a Spectrum emu-val akad össze, majd azt átpakolom máshova.)
No igen, ott legalabb lehet pakolni :( Szemezgettem regebben az eZ80-al ami akar 50MHz-en is menne (es 4x sebesseg azonos orajelen is kb) csak ott a full 00-FF I/O tartomany belso celra foglalt, es errol nem lehet lebeszelni a dox szerint :( Pedig integralt SPI busztol kezdve ethernet minden lenne benne, erdekes otleteket vethetne fel egy epitsunk EP-t project kapcsan ... Feelingre lehetett volna egy 200MHz-es Z80 kb akkor :) Arra mar Pgyuri se mondana h lassu a CPU a grafikahoz :) :) Node persze vissza a realitasok talajara, eloszor ki kene cserelni a mezei Z80A-t a hibas EP-mben, eZ80 majd par evtized mulva talan :)
-
Ugyanez a baj a Z380-al is :-(
-
Amugy nem is ertem ... Irjak mindenhol (pl eZ80-nal is) hogy nagy elonye a kompatibilitas, akar regi rendszerekbe/design-ba is rakhato stb. Akkor viszont rajohetenenek, hogy ez gond, mert ott ugye altalaban hasznalnak a kerdeses portokat mar eleve! Anno irtam Zilog supportnak ez ugyben :) Udvariasan valaszoltak (tobb levelet is valtottunk) de lathatoan nem ertettek a problemat, hiaba magyaraztam el. Raadasul eZ80 (de amugy sima Z80-nal is) valojaban 16 bitet rak ki a cimbuszra I/O muvelet eseten is, tehat siman lehetne a belso cuccokat pl 100-1FF tartomanyba tenni. eZ80-on raadasul "kivul" a buszon meg se jelenik semmi ha belso I/O portra megy a keres, tehat meg azzal sem kene foglalkozni, hogy figyelni erre (bar azert nem ilyen egyszeru, ha jol remlik OUT (C),.... ize eseten az egesz BC-t kirakja, arra meg legtobb program ugye nincs felkeszulve hogy a B erteke is megfelelo legyen - peldamban veletlenul ne egy). Ehhh, nehez ugy :(
Viszont, ha mar I/O: Zozo, te biztos fejbol is megmondod :) Tegyuk fel hogy van egy OUT majd azonnal utana egy IN (leheto legekevesebb orajel ciklusu "verzio" mindket utasitasbol!). Szerinted hany orajel ciklus (t-cycle?) van akkor a ketto kozott, ha ugy nezzuk, hogy az OUT-nal onnan szamoljuk, amikor megjelenik a buszon a muvelet, es odaig szamitjuk, amikor az IN szamara a buszra kell mar tenni. Ezt probaltam kitalalni magam, de sajna csak az utasitasok ossz hosszara latok utalast, arra nem, hogy azon belul pontosan melyik ciklisban mi tortenik. Illetve jo lenne ezt tudni pl Z180 esetere is, ha mar beszeltunk rola. Ha veletlenul tudsz ilyet fejbol (nem akarok hazaifeladatot adni ...), megkoszonnem!
Ebbol kitalalhato, hogy pl mikrokontrollert alkalmaznek az EP buszra akasztva, csak azt akarom kiszamolni, hogy mennyi idom van "reagalni", hogy adott X EP Z80 orajelen tutira mukodjon (figyelmbe veve az esetleges turbositas stb tenyet is esetleg).
-
11 :-)
4 az utasítás bájt, 3 a portcím, 4 az I/O művelet
Z180-on 9
-
Eszembe jutott valami: van/lehet olyan helyzet, hogy normal 4MHz-es Z80 OK, de gyorsabb CPU eseten adott I/O muvelet problemas. Nem lehetne EXOS2.4-be olyat tenni, hogy a CPU info (cpu tipus, mert orajel) pl eltarolja? Vmi exos valtozoba, vagy tudomisen. Mert akkor ha pl van egy rendszerbovito, ahol ez problemas lehet, nem neki kell mericskelnie, kitalalnia, hanem megprobalhatja megkerdezni, hogy milyen hw-n fut, es pl "tul gyors" cpu eseten a nop-al megspekelt I/O rutint hasznalja, amugy meg az enelkulit. Persze, nem tudom mi van ha menet kozben valt vki orajelet (ha van ilyen turbositas jelenleg egyaltalan?), illetve hogy mi van, ha vki regebbi exos-szal nyomul. Van ennek ertelme? Annyi biztos lenne, hogy pla sysinfo szeru program lekerdezhetne a cpu-t is (akar azt is h cmos/nmos) nem maganak kell detektalnia, felteve ha az adott exos ezt mar tudja :)
-
mi van ha menet kozben valt vki orajelet (ha van ilyen turbositas jelenleg egyaltalan?)
Az SMD Turbo az ilyen.
Az említett problémára van a WAIT vezeték, ott tud szólni az eszköz, hogy még nincs készen.
A távlati terv egyébként az lenne, hogy a felső RAM panel helyére menne egy Z180+turbo+RAM bővítés. A Z80 is megmaradna (kompatibilitási okokból), a két proci átkapcsolható lenne, meg persze az órajel is, szoftverből is (IO port). Az aktuális állapot meg lekérdezhető lenne IO porton.
-
Az SMD Turbo az ilyen.
Az említett problémára van a WAIT vezeték, ott tud szólni az eszköz, hogy még nincs készen.
A távlati terv egyébként az lenne, hogy a felső RAM panel helyére menne egy Z180+turbo+RAM bővítés. A Z80 is megmaradna (kompatibilitási okokból), a két proci átkapcsolható lenne, meg persze az órajel is, szoftverből is (IO port). Az aktuális állapot meg lekérdezhető lenne IO porton.
Ah, WAIT. Na meg egy dolog, amire meg nem gondoltam :D Mondjuk az a ciki, hogy adott esetben pl 4MHz-en mondjuk eppen "belefer " az MCU idejebe, de turbonal mar nem. Ha erre gondolva mindig a WAIT-et hsznalom, akkor mar viszont 4MHz-en sem fer bele ;-( Tekintve hogy X orajelciklus az MCU-n, hogy WAIT-et beallitok, es minden orajel ertekes mar. Igy viszont alapgepen is lassabb lesz mint lehetne csak azert, hogy gyorsabb gepen is kepes legyen mukodni. En azert gondoltam arra, hogy akkor mar inkabb EP-n megprobalom kitalalni a Z80 orajelet, es attol fuggoen hasznalok "mestersegesen" NOP-okat, hogy "tul gyors" e a Z80 vagy az alap frekin porog.
Es a flash hova? :) Amugy jol hangzik. Tul jol is, szinte mar mesebe illo lenne :) Esetleg meg egy kis AVR elferne oda, oszt lenne SPI busz a gepben maris, amire lehet majd pl az SD kartyat pakolni.
-
A 2.4 tesztje nem indult el :oops: lecseréltem az összes nem dokumentált Z80 utasítást, most már megy :-)
Kíváncsi vagyok, vajon hány EP program használ nem dokumentált utasításokat, azokat akkor mind újra kéne írni. Ha jól emlékszem, mintha a HEASS-ban implementálva is lettek ezek az ASM utasítások (pl. INC IXH stb.), de lehet, hogy rosszul emlékszem.
-
A fél index regiszteresek már a Fenassban is benne voltak, de a HEASS-ban az összes többi is.
Az majd további kutatásokat igényel mi az ami megy Z180-on mi az ami nem.
Minden esetre nem véletlenül gondolkodok átkapcsolható procis rendszerben. Ha sikerül amit kitervelek, akkor majd új EXOS hívás lesz a proci váltásra :-)
-
HEASS-ba majd bele kell rakni a Z180-as utasításokat is :-)
Kigyűjtöttem őket, de még van némi bizonytalanság, ott ahol az F vagy a (HL) adódik paraméterként, hogy ténylegesen mi történik.
-
A fél index regiszteresek már a Fenassban is benne voltak, de a HEASS-ban az összes többi is.
Az majd további kutatásokat igényel mi az ami megy Z180-on mi az ami nem.
Minden esetre nem véletlenül gondolkodok átkapcsolható procis rendszerben. Ha sikerül amit kitervelek, akkor majd új EXOS hívás lesz a proci váltásra :-)
Huh menet kozben procit valtani? :) Trukkos, mert gondolom le kene menteni registereket stb, aztan szolni a masik Z80-nak (pl addig BUSRQ-val van megfogva?) hogy mehet, csakhat akkor o honnan kezdi ... Lehet RESET jelet kene neki kuldeni, akkor meg persze tudni, hogy utana szedje fel a regisztereket, interrupt allapotot, miegymast ...
-
BUSREQ/BUSACK-al van elképzelve a dolog.
Lenne egy I/O portos bit ami kapcsolna, és amikor az eddig futó proci megadja a BUSACK-ot, akkor szűnne meg az eddig állón a BUSREQ.
Programilag egy fix ROM rutinban menne, ahol DI után kiadja az átkapcsoló OUT-ot, majd várakozási ciklus. A várakozási ciklus közben lesz megállítva.
Majd amikor újra sorra kerül, akkor a ciklus vége után egy fix címről veszi az SP-t, és utána mehet a visszatérés. Mivel EXOS hívásként lenne, az EXOS úgyis mentett mindent ami a felhasználó program számára érdekes.
Az egészben ami érdekes kérdés: mi történik amikor Resetnél aktív a BUSREQ? Egyből megáll mielőtt mást csinálna?
Ha igen, akkor egyszerű, reset után elviszi az első procit az átkapcsoláshoz, és a másikkal fogja az eredeti reset rutint végrehajtani.
Ha ez nem jön be akkor órajel szüneteltetési játék is kell.
-
BUSREQ/BUSACK-al van elképzelve a dolog.
Lenne egy I/O portos bit ami kapcsolna, és amikor az eddig futó proci megadja a BUSACK-ot, akkor szűnne meg az eddig állón a BUSREQ.
Programilag egy fix ROM rutinban menne, ahol DI után kiadja az átkapcsoló OUT-ot, majd várakozási ciklus. A várakozási ciklus közben lesz megállítva.
Majd amikor újra sorra kerül, akkor a ciklus vége után egy fix címről veszi az SP-t, és utána mehet a visszatérés. Mivel EXOS hívásként lenne, az EXOS úgyis mentett mindent ami a felhasználó program számára érdekes.
Az egészben ami érdekes kérdés: mi történik amikor Resetnél aktív a BUSREQ? Egyből megáll mielőtt mást csinálna?
Ha igen, akkor egyszerű, reset után elviszi az első procit az átkapcsoláshoz, és a másikkal fogja az eredeti reset rutint végrehajtani.
Ha ez nem jön be akkor órajel szüneteltetési játék is kell.
Menjen ket CPU-val egyszerre, memhozzaferesek stb szinkronizalva, aztan lesz ket procis EP :) Na jo, komolyra forditva a szot: ez oke, csak tenyleg reset/bekapcsolas utan mi van? Imho, amugy annyi terv van, lasd a "feladvanyt", ezt stb, hogy ezt diszkret aramkorokbol megepiteni egesz szep terepasztal lesz lassan mar. Lehet, vmi GAL vagy meginkabb CPLD kellene (FPGA azert kicsit sok) amivel ez egyszeruen megoldhato. A reset jelnel meg resetelni kene azt a pl flip-flopt ami eloallitja a BUSREQ-t, igy mindig adott CPU indul el, vagy rosszul gondolom? Max EXOS cpu-atkapcsolo hivasa lejegyezhetne egy exos valtozoba h melyik cpu volt aktiv, igy ha vki reset gombot nyom, az alapjan visszaallitja aztan mielott atadna a vezerlest az exos warmstart system page-n levo cimre.
-
Imho, amugy annyi terv van, lasd a "feladvanyt", ezt stb, hogy ezt diszkret aramkorokbol megepiteni egesz szep terepasztal lesz lassan mar.
A feladvány 3 IC.
Szerintem az egész bőven belefér a felső RAM panel méretébe, és még IC se lesz annyi rajta!
-
A feladvány 3 IC.
Szerintem az egész bőven belefér a felső RAM panel méretébe, és még IC se lesz annyi rajta!
Ja, de ha hozzaveszed meg a plusz dolgokat, hogy Z80/Z180 atkapcsolas, turobositas, kapcsolhato orajellel, stb, ahogy jonnek meg az otletek folyamatosan :) A shadow RAM-os dolog ... Nick-3D hw gyorsitas ... oppsz ez utobbi megse :)
-
Minden esetre nem véletlenül gondolkodok átkapcsolható procis rendszerben. Ha sikerül amit kitervelek, akkor majd új EXOS hívás lesz a proci váltásra :-)
Zozo, nem semmi vagy! :-)
-
Ez ma érkezett:
[attach=1]
Plusz jött még - remélem tényleg valódi - 20MHz Z80, kikutatni a legvégső határt :-)
És végre találtam Z8S18020PSG-t! :-D
-
Plusz jött még - remélem tényleg valódi - 20MHz Z80, kikutatni a legvégső határt :-)
... es eljutni oda, ahova az Enterprise meg nem mereszkedett. Es itt az Enterprise is stimmel :)
Btw, Z180, az IX es IY regiszterek "kettebontasa" az ugye kevesbe hivatalos ugymond (?), de a Z180 ezt tudja? Mert irtad, hogy SymbOS hasznal olyasmit, amit Z180 nem fog tudni, csak nem teljesen fogtam elosre, hogy pontosan melyik opcode-okra gondolsz ...
-
Es itt az Enterprise is stimmel :)
Nem véletlenül írtam :-D
Btw, Z180, az IX es IY regiszterek "kettebontasa" az ugye kevesbe hivatalos ugymond (?), de a Z180 ezt tudja?
Nem, csak a hivatalos opkódokat tudja.
-
A képen látható cuccot felismerted? Az ügyben te vagy a felbujtó :-)
-
A képen látható cuccot felismerted? Az ügyben te vagy a felbujtó :-)
Mindent tagadok :) Amugy tippelnek: dual port RAM?
-
Amugy tippelnek: dual port RAM?
Azaz, 64KB! Ezzel meg lehetne szabadulni a Nick-kel egyezkedés kényszerétől :-)
-
Azaz, 64KB! Ezzel meg lehetne szabadulni a Nick-kel egyezkedés kényszerétől :-)
Hehe, na ja :) Optimalis esetben szerintem az lenne a szep, ha vmi I/O porton allithato lenne _ennek ellenere_, hogy nick fogja meg a Z80-at az orajellel jatszva, igy sw-bol kapcsolhato, hogy az idozites az "eredeti" legyen vagy turbo vram z80 access speed :)
Az lenne meg show, ha 128K is lenne, es akkor csinalni 128K videoRAM-ot :) Nick kedveert meg flip-flop stb odarak, hogy melyik 64K-s reszet lassa eppen. Mondjuk ertelme nem sok, max lehet tobb kepet valtogatni stb, ha tobbszoros puffereles/miegymas van.
Amugy errol meg az jutott eszembe, hogy lassan lehetne epiteni egy uj EP-t sajat nyak-on. Foleg, ha az ember le tud mondani par "extra" dologrol (printer port, serial port, miegymas). Akkor kene kb egy dual port RAM :) egy kitermelt Nick. A Nick voltakeppen csak a DP ram egyik portjan olvas, szoval Z80 mehetne akar 33Mhz-en is :-/ Max gondolom IO wait azert kene, ha Z80 a nick portokat piszkalja. A masik problema viszont a dave-nel lenne, tartok tole, hogy nem birna a tul magas orajelet, es oda is kene vmi IOWAIT ha dave portokat piszkal az ember. Max itt ugye a gaz, hogy a Dave amugy a lapozast is csinalja, lehet, emiatt kene implementalni "kivulrol" negy latch-et vagy hasonlot, ami B0...B3 irasnal szerephez jut, es valojaban ezt hasznalja a cimzes, nem a dave-bol jovot.
Ezek mellett jo sok RAM meg egy rakas ami a DP-s videoram mellett van.
Na jo, ez kisse meredeken hangzik :) Viszont szerintem egesz kicsiben megoldhato lenne.
Ez amugy arrol jutott eszembe, hogy vmi Ben Heck (?) vagy mi showban volt, hogy a csavo hordozhato Spectrumot epitett :) Vegulis sajat panelre osszarakott modern SRAM-ot, vmi ROM-ot, Z80-at, viszont az ULA-t eredeti spectrumbol eszedte, igy viszont egesz kicsire ossze tudta zsufolni. Na, ezekbol jutott eszembe, hogy EP-t is lehetne "ujraimplementalni", ha az ember megtartja a custom IC-ket csak (Dave, Nick). Es most akkor ugye FPGA-ban felepitjuk a dolgot cimu jatekrol nem beszeltem, mert az megint kicsit mas kerdes ...
-
Hehe, na ja :) Optimalis esetben szerintem az lenne a szep, ha vmi I/O porton allithato lenne _ennek ellenere_, hogy nick fogja meg a Z80-at az orajellel jatszva, igy sw-bol kapcsolhato, hogy az idozites az "eredeti" legyen vagy turbo vram z80 access speed :)
Ez teljesen egyértelmű :-)
Csak a /VRAM vezetéket kell kapcsolgatni, hogy eljut-e a Nick-hez vagy se.
Az lenne meg show, ha 128K is lenne, es akkor csinalni 128K videoRAM-ot :) Nick kedveert meg flip-flop stb odarak, hogy melyik 64K-s reszet lassa eppen. Mondjuk ertelme nem sok, max lehet tobb kepet valtogatni stb, ha tobbszoros puffereles/miegymas van.
Sok értelme nem lenne, de legalább jó drága lenne. Ez a 64KB is 17000 forint... :oops:
Amugy errol meg az jutott eszembe, hogy lassan lehetne epiteni egy uj EP-t sajat nyak-on.
Ilyenre is gondoltam már... csak nálunk nem olyan egyszerű átrakni a Dave-t meg a Nick-et, mint a Spectrumos ULA-t :-(
-
Plusz amit emlitettem regebben: kene egy R800 CPU is a poen kedveert, az elvileg Z180-al ellentetben tudja kb az undocumented Z80 opcode-okat is (legalabbis IX/IY bontasat igen ...), viszont durvan sokkal gyorsabb azonos orajelen is. Elvileg talan MSX turbo gepekhez terveztek Japanban. Az biztos, hogy nick/dave-el egyuttmukodni nem tudom mennyire lenne neki egyszeru, gondolom a clock deformalas a nick altal cimu jatekon csufosan elbukna, de egy "szabadabb, ujraepitos" jatekban azert erdekes lenne latni ezt a CPU-t, plane ha meg orajel is magasabb ...
http://en.wikipedia.org/wiki/R800_%28CPU%29 (http://en.wikipedia.org/wiki/R800_%28CPU%29)
-
R800-al az a baj, hogy ezer éve nem gyártják, és beszerezhetetlen. Míg a Z180 mai napig gyártásban van.
-
R800-al az a baj, hogy ezer éve nem gyártják, és beszerezhetetlen. Míg a Z180 mai napig gyártásban van.
eZ80 sem lenne rossz, mint volt mar rola szo, csak ugye lefoglaltak a 0-FF I/O tartomanyt fixen, es nem tudod rola lebeszelni :( Most lattam, az eZ80 csaladban van olyan peldany aminek csak 128db I/O cim kell, de pechunkre pont a 80-FF a foglalt, es ha jol latom nem valtoztathato, mint Z180-on talan :( Ha meg a masik fele lenne ... Szal egyetlen biten mulik a dolog (bit#7). Masreszt, eZ80 lehet szinten nem ismerne az undocumented opcode-okat? ;( R800-at amugy multkor lattam ebay-en, bar ez nyilvan meg siralmas mindig, ha ma is "normalisan" kaphato Z80 es Z180-at nezzuk ... Lehet, marad majd megis az FPGA :) Ha valaki ertene hozza, akinek van kedve vele foglalkozni.
-
mint Z180-on talan
Nem csak talán :-) alapból 00-3Fh, amit az EXOS 2.4 induláskor átpakol 40-7Fh-ra, hogy az EXDOS-sal ne akadjon össze.
-
A Z8S180-ban meg az a poén, hogy tud teljes órajelen járni, nem csak a felén. Így hátha nem szívatja meg annyira a Nick :-)
-
A Z8S180-ban meg az a poén, hogy tud teljes órajelen járni, nem csak a felén. Így hátha nem szívatja meg annyira a Nick :-)
Vagy johet a wait state generator az orajel bizeralasa helyett ...
-
Vagy johet a wait state generator az orajel bizeralasa helyett ...
Próbálkoztam, de még nem sok sikerrel :-(
-
A Z8S180-ban meg az a poén, hogy tud teljes órajelen járni, nem csak a felén. Így hátha nem szívatja meg annyira a Nick :-)
Abból a szempontból siker, hogy így már egy sima gépbe berakva, nem 2MHz-en fog menni a proci, BASIC promptnál nézve normálnak tűnik.
Gyári EXDOS kártyával megy a floppy is. (Próbáltam az SD-t is az DIR-nél behalt :oops: de érdekes módon az EXDOS.INI-t még betöltötte.)
Néztem az OTW64-et (Magicball eredeti, 64-es változata), az fut viszont játék közben kiderül, hogy még nem tökéletes a Nick szinkron :-( játék közben kb fele sebesség lesz, a zene is lassú. De pl a high score beírásnál (ahol nem rajzol sok grafikát) már jó a zene.
Panicman használhat nem dokumentált utasításokat, fent a státusz sort teleszórta pacman figurákkal, egy idő után meg leesett a pályáról, és itt megállt a dolog, mert meghalni se lehetett :-)
-
Panicman használhat nem dokumentált utasításokat, fent a státusz sort teleszórta pacman figurákkal, egy idő után meg leesett a pályáról, és itt megállt a dolog, mert meghalni se lehetett :-)
Orokelet CPU szintu hw tamogatassal, nem semmi :)
-
És akkor most mittud a Z180 a 10 MHz -es (láttam én ott 12 MHz -es fotót is!) CMOS Z80 -hoz képest ? Mennyivel tud a Z180 többet ? Mert ugye a nem dokumentált utasításoknál meg megy negatívba a mérleg ...
-
Itt hátrébb pár lappal (tavaly májusban) raktam be egy XLS-et ami összehasonlitja a végrehajtási idöket. Plusz van pár uj utasitás is.
-
Megvan ... de mire jó ez a tábla ?
Mik azok a százalékok, mihez képest vannak felvéve ?
És akkor ezt a Z180 -at is ugyanúgy 10 MHz -en lehetne max hajtani mint a CMOS Z80 -at ?
-
Mik azok a százalékok, mihez képest vannak felvéve ?
4MHz-es Z80-an hoz képest. Azonos órajelen olyan átlag 20-25%-al gyorsabb.
És akkor ezt a Z180 -at is ugyanúgy 10 MHz -en lehetne max hajtani mint a CMOS Z80 -at ?
Ha bejön a Dual Port SRAM trükk, akkor ki lesz hagyva a játékból a Nick, akkor lehet, hogy tovább is lehet jutni.
Ez amúgy igaz a sima Z80-ra is.
-
4MHz-es Z80-an hoz képest.
Hát én úgy láttam, hogy épphogy az is szerepel benne ...
Azonos órajelen olyan átlag 20-25%-al gyorsabb.
Na így már én is értem ...
Ha SymbOS nincs, akkor nem rossz, de ha SymbOS van,
és lehet SymbOS kompatibilisen 250% -ot gyorsítani,
vagy SymbOS inkompatibilisen 312.5% -ot ...
Hát az egy adott gépnél már elég kérdéses lesz akkor ...
-
Hát én úgy láttam, hogy épphogy az is szerepel benne ...
Hol? Én csak 4MHz Z180-at láttok.
-
Itt:
http://enterpriseforever.com/hardver/hardware-hogyan-apritsuk-miszlikbe-enterprise-unkat/msg32811/#msg32811
Én visszamentem májusig ... ahogy írtad ... :)
-
Itt:
http://enterpriseforever.com/hardver/hardware-hogyan-apritsuk-miszlikbe-enterprise-unkat/msg32811/#msg32811
Én visszamentem májusig ... ahogy írtad ... :)
És ott hol láttál 4MHz Z80-at? A táblázatban az van, hogy a 4, 6, 7.12Mhz-es Z180 mennyivel gyorsabb mint az alap 4MHz Z80.
-
s ott hol láttál 4MHz Z80-at? A táblázatban az van, hogy a 4, 6, 7.12Mhz-es Z180 mennyivel gyorsabb mint az alap 4MHz Z80.
Kevesebbet kéne innom ... :)
-
Nem, csak a hivatalos opkódokat tudja.
Az IXL, IXH, IYL, és IYH regiszterek hiánya azért elég komoly hátrány, ami sok programot elronthat. Nem biztos, hogy így megéri-e a legfeljebb 20-25%-os gyorsulás a "normál" (teljesen kompatibilis) turbósított Z80-hoz képest.
-
Nem biztos, hogy így megéri-e a legfeljebb 20-25%-os gyorsulás a "normál" (teljesen kompatibilis) turbósított Z80-hoz képest.
IS-BASIC-nek pl jól jön minden lóerő :-)
Amúgy meg mindenképpen átkapcsolható rendszerben gondolkodok. Csináltak ilyet pl MSX-re is.
-
Az IXL, IXH, IYL, és IYH regiszterek hiánya azért elég komoly hátrány, ami sok programot elronthat. Nem biztos, hogy így megéri-e a legfeljebb 20-25%-os gyorsulás a "normál" (teljesen kompatibilis) turbósított Z80-hoz képest.
Amugy nem hasznos mas miatt is a Z180 (nem csak a 20-25% gyorsulas, ugy ertem)? Tudomisen, a beepitett DMA controllere pl hasznalhato lenne? Ha jol remlik az is van benne. Meg meg ki tudja, mi ...
-
Amugy nem hasznos mas miatt is a Z180 (nem csak a 20-25% gyorsulas, ugy ertem)? Tudomisen, a beepitett DMA controllere pl hasznalhato lenne? Ha jol remlik az is van benne. Meg meg ki tudja, mi ...
Igen a DMA még hasznos tudna lenni. Van még mindenféle soros portos ökörség, az engem nem izgat különösebben :-)
-
Az UART sem haszontalan, ha akarsz soros portot, pl PC-vel osszekotni normalis sebesseggel, tudomisen. Egy kis EXOS szorakozas, es pl a SERIAL: dolgokat ra lehetne iranyitani, aztan valami "valodi" es foleg gyors soros port is lenne egyben. Marmint talan .........
-
Mihez kellett a dual port ram ? A szokásos "gyorsan felelni az EP -nek miközben szép lassan állítgatjuk" problémához ?
Vagy valami speciális ?
-
Vagy valami speciális ?
Videó memóriának, hogy a proci meg a Nick egyszerre férjen hozzá, azaz a proci is teljes sebességgel érje el. És így nem kell a Nickkel szinkronizálni sem, mindkettő azt csinál amit akar :-)
-
Videó memóriának, hogy a proci meg a Nick egyszerre férjen hozzá, azaz a proci is teljes sebességgel érje el. És így nem kell a Nickkel szinkronizálni sem, mindkettő azt csinál amit akar :-)
De bakker, ha jól értem én amit motyogsz,
akkor ez nem a sprite (vagy más extra) hardverhez kell,
hanem felszabadítottad a video ram -ot a sebesseglassulás alól ? :)
Magyarul ilyen konfignál nincs sebességkülönbség a 2 ramtípus között ? Ha így van, hogyhogy nem vered nagy dobra ?
Mellesleg érteném én, hogy mivel a NICK csak olvas, sosem ír, ezért nem lehetnek prioritási problémák,
de azért valahol egy ilyen dual port ram is felold valamiféle ütküzést, pld. egyik ír, másik olvas szituációt ... nyilván nem adhat vissza félig írt byte -ot, stb ...
Tehát ott váratnia kell ... ez a váratás sokkal gyorsabb, mint amit az EP ramjaival összehoztak ?
-
De bakker, ha jól értem én amit motyogsz,
akkor ez nem a sprite (vagy más extra) hardverhez kell,
Ez a megagigasuperturbo kártyához kell :-)
hanem felszabadítottad a video ram -ot a sebesseglassulás alól ? :)
Magyarul ilyen konfignál nincs sebességkülönbség a 2 ramtípus között ?
Így van.
Tehát lenne 3 mód:
Z80 hagyományos videó RAM eléréssel, 4-10Mhz-ig
Z80 gyors videó RAM eléréssel, 10Mhz biztos, de mivel kikerül a Nick szinkron a dologból, lehet, hogy nagyobb órajel is elérhető.
Z180 gyors videó RAM eléréssel, 10Mhz biztos, de mivel kikerül a Nick szinkron a dologból, lehet, hogy nagyobb órajel is elérhető.
Ha így van, hogyhogy nem vered nagy dobra ?
Itt volt :-) (http://enterpriseforever.com/hardver/hardware-hogyan-apritsuk-miszlikbe-enterprise-unkat/msg42095/#msg42095)
Most prototípus NYÁK gyártásán gondolkodok, mert ilyen sok lábú cuccot már nincs kedvem bedrótozni :-)
de azért valahol egy ilyen dual port ram is felold valamiféle ütküzést, pld. egyik ír, másik olvas szituációt ... nyilván nem adhat vissza félig írt byte -ot, stb ...
Tehát ott váratnia kell ... ez a váratás sokkal gyorsabb, mint amit az EP ramjaival összehoztak ?
Nem várat, magában lekezeli, gondolom belső pufferekkel. Pont ez a lényege :-)
-
Most prototípus NYÁK gyártásán gondolkodok, mert ilyen sok lábú cuccot már nincs kedvem bedrótozni :-)
Meg hát nem is értem hogy gondolnád dróttal ...
Meg úgy egyáltalán nem értem ... mégha lennének valami kivezetés nyákok, de arra is be kell tudni forrasztani ... foglalatos kivezetés nyák úgysem lesz ...
Ez a megagigasuperturbo kártyához kell :-)
Lehet hogy ahhoz kell, de beszerelési nehézségeket nem tekintve, egy teljes alap EP -be is jól jöhetne önmagában, video ram lassulást eliminálni, nem ?
-
Meg hát nem is értem hogy gondolnád dróttal ...
Meg úgy egyáltalán nem értem ... mégha lennének valami kivezetés nyákok, de arra is be kell tudni forrasztani ... foglalatos kivezetés nyák úgysem lesz ...
Van hozzá PLCC84 foglalat rendes lábakkal, ami kezelhetővé teszi :-)
Lehet hogy ahhoz kell, de beszerelési nehézségeket nem tekintve, egy teljes alap EP -be is jól jöhetne önmagában, video ram lassulást eliminálni, nem ?
Igen, de ha már úgyis rá lesz téve egy panelre, akkor simán mellé dobható turbó kártya is :-)
Még az SMD turbókártyáról kell kideríteni, hogyan csinálják a tuti lefagyás mentes átkapcsolást, a lereszelt tetejű IC-kről kell kitalálni micsodák is...
-
mivel kikerül a Nick szinkron a dologból, lehet, hogy nagyobb órajel is elérhető.
Konkrétabban: 20Mhz rendszerórajel ott van már, amikor 10Mhz-en megy a Z80.
Ha a Nick szinkron kikerül a képből, meg lehetne nézni, mi lesz ha az a 20Mhz megy egyből a procinak is :-) Itt majd Dave, memória címdekódolás kérdése jön majd.
-
Még az SMD turbókártyáról kell kideríteni, hogyan csinálják a tuti lefagyás mentes átkapcsolást, a lereszelt tetejű IC-kről kell kitalálni micsodák is...
Ugyan gőzöm nincs milyen SMD turbókariról beszélsz,
de nagyon érdekes EP -s idők járnak mostanában ... :)
Mondjuk emlékszem hogy év elején is ezt mondtam, és valszeg minden (valami késznek tekinthető verziók) átcsúszik jövőre szinte kivétel nélkül (SD,SymbOS,turbók,inputok),
talán a ram bővítők az egyetlen, ami idén is már teljesen final -nek mondható,
de a jövő év végére szerintem olyan dolgok lesznek, amiről én személy szerint még csak nem is álmodtam soha ... :)
-
Ugyan gőzöm nincs milyen SMD turbókariról beszélsz,
Erről. (http://gafz.enterpriseforever.com/Galery/Bovitmenyek/Picture/SDM_Turbo~1.jpg) Ott álltak sorban érte a népek az EP Klubban a Fehérvári úton, 1992-ben :-)
Beszerelési útmutató (http://gafz.enterpriseforever.com/Hardware/Turbo/Picture/SMD_Turbo.jpg)
Amikor a 3. gépünkbe már nem jutott, akkor találtam ki a 7.12Mhz trükköt, mint low cost turbót :-)
de nagyon érdekes EP -s idők járnak mostanában ... :)
Mondjuk emlékszem hogy év elején is ezt mondtam, és valszeg minden (valami késznek tekinthető verziók) átcsúszik jövőre szinte kivétel nélkül (SD,SymbOS,turbók,inputok),
talán a ram bővítők az egyetlen, ami idén is már teljesen final -nek mondható,
de a jövő év végére szerintem olyan dolgok lesznek, amiről én személy szerint még csak nem is álmodtam soha ... :)
Végülis a 30 éves évfordulót illik megünnepelni :-)
-
Erről. Ott álltak sorban érte a népek az EP Klubban a Fehérvári úton, 1992-ben :-)
Ja ... hogy ez úgy "SMD" ahogy én "Z80System" vagyok ... :)
(Már hogy annyi a köze az SMD -hez ... :))
De ez ugye sosem volt 12 Mhz, ez egy síma 6 MHz dolog (Z80 oldalon), nem ? Szóval nem 3X sebeség csak 1.5X ...
-
Ja ... hogy ez úgy "SMD" ahogy én "Z80System" vagyok ... :)
Egész konkrétan Sanyi, Miki, Dodó a jelentése :-)
De ez ugye sosem volt 12 Mhz, ez egy síma 6 MHz dolog (Z80 oldalon), nem ? Szóval nem 3X sebeség csak 1.5X ...
Igen, a rendszerórajel az mindig kétszerese a Z80-nak, és a Nick osztja le.
Az extrája a kártyának a garantáltan fagyás mentes átkapcsolás, ami akkor is működik, amikor én 10MHz-et használok a 4 helyett.
-
Ha nem gond, nyitok itt egy uj temat Z180 kapcsan ...
Szoval, ha Z80-on egy normal (nem CB es ED -s) opcode-ot prefixal az ember DD/FD-vel mint pl az "LD A,B"-t, akkor ha minden igaz a Z80 ezt ugy hajtja vegre, mintha a DD/FD ott sem lenne. Illetve persze nem teljesen, mert 4 T-state-et elvisz a prefix ertelmezese, de eredmenyeben legalabbis, mintha ott sem lenne. Ezert felteteleztem, hogy Z180-on ugyanez tortenik, ahol IXH/IXL/IYH/IYL lenne, mivel a Z180 nem tudja IX/IY-t "felbontani", szerintem ez lehet a logikus mukodes (erdekes parhuzam, hogy x86-on hasonlo az SI/DI regiszterek: mig pl a BX felbonthato BL es BH-ra, az SI/DI nem). Ez elvileg Z80-on egyszeruen ellenorizheto szerintem: pl INC IXH/IYH es INC IXL/IYL -nel Z180-on meg kell nezni, hogy a H illetve L novekszik-e, ha igen, akkor a fenti feltetelezesem valoszinuleg igaz.
A CB opcode-ok kerdese erdekesebb. http://mdfs.net/Docs/Comp/Z180/OpList szerint legalabbis hianyzik a 0x30-0x37, hogy itt mit csinal a Z180 az jo kerdes. A DD/FD prefixalt CB opcode-ok esete talan kicsit jobban megjosolhato. Itt minden 8 opcode-bol egy ertelmezett csak, ha minden igaz. Errol Z80 doksik - emlekeim szerint - azt irjak, hogy _altalaban_ egy Z80 a tobbire ugy viselkedik, hogy ugye egy regiszterbe is beteszi az eredmenyt. Itt azonban meg is jegyeztek - szinten emlekeim szerint - hogy ez a mukodes nem garantalt, es "van ahol" siman ugyanazt csinalja, mint a "hivatalos" opcode abbol a 8-as "blokkbol". Lehet a Z180 pont ilyen? Itt is van egy lyuk 0x30-0x37-nel persze.
Utolsokent maradtak az ED-s opcode-ok. Ezek nem prefixalhatoak Z80-on sem, ED-s opcode elott DD/FD-nek nem lesz hatasa az opcode mukodesere. Ugy nez ki, ED-sek koze pakoltak a Z180 uj utasitasait. Z80-on van par opcode ami lathatoan nem dokumentalt modon uazt csinalja mint egy masik - hivatalos - opcode. Ezert a nem dokumentalt ED-s opcode-oknak szerintem Z80-on sincs sok haszna, igy remelhetoleg nem is nagyon hasznalja senki. Ui Z180 pl tett oda uj utasitasokat, ami Z80-on nem dokumentalt modon vmit azert csinal, amde az megtalalhato masik opcode-on is "hivatalos" formaban. Nem tudom, jol gondolom-e ...
-
Bar sok valasz meg nem jott :) Azert irok kerdest meg, az elozo hozzaszolasomhoz. Ahogy latom, harom esetet lehet/erdemes emulalni: NMOS Z80, CMOS Z80, Z180 (ebbol csak CMOS van, vagy legalabbis sw szempontbol nincs kulonbseg, ha van is NMOS)? Amennyire tudom Z80-nal az NMOS/CMOS kulonbseg ott latszik, hogy az LD A,R es LD A,I -nel van talan vmi hiba. Illetve a nem dokumentalt (?) nullat irok ki az I/O portra, ahol CMOS-nal 0xFF-et fog. Mas kulonbsegrol nem tudok. Z180-nal az LD A,R es LD A,I hibak akkor nincsenek, tehat az (ilyen szempontbol!) a CMOS Z80 viselkedesenek felel meg? Az az OUT -os cucc meg Z180-nal imho nem jatszik mert az Z80 undoc opcode volt (ha minden igaz ...) ergo Z180 ugy sem tudja mar eleve (?).
Azert kerdezek ennyit, mert ha mar hozzanyulok a z80ex-hez, akkor jo lenne, ha tudna Z80 CMOS/NMOS-t illetve Z180-at is emulalni (ez utobbit nem feltetlenul annyira pontosan, pl idozites biztos nem lesz ua, mert ugye Z180-nal egyes opcode-ok gyorsabbak, ezt kicsit nagyobb munka lenne mindenhol ellenorizni utasitasokkent).
-
Ha majd a valódi gép közelébe jutok, akkor meg tudom nézegetni a dolgokat.
-
Ha majd a valódi gép közelébe jutok, akkor meg tudom nézegetni a dolgokat.
Koszi elore is! Nem turelmetlen voltam, csak elnezest kertem volna, hogy megint kisregenyeket irok egy temaban :oops:
Viszont a masik kerdes: nezegettem forumot, de szokas szerint nem talalom (a valo eletben se talalok soha semmit, kerdezd a felesegemet ...), hogy mi volt egesz pontosan az osszes kulonbseg a CMOS es az NMOS Z80 kozott. Ahogy irtam elozo hozzaszolasomban itt, fejbol nagyjabol megvan, de hogy "bit szinten" mit jelent mindez, az erdekelne az emulacio erdekeben.
Kozben irtam "CMOS emulaciot", igaz, barmivel aktivalni ki/be kapcsolni meg nem lehet :(
-
Amennyire tudom Z80-nal az NMOS/CMOS kulonbseg ott latszik, hogy az LD A,R es LD A,I -nel van talan vmi hiba.
Igen, a megszakítás állapotot amikor ezekkel lekérdezed, és pont ott jön egy megszakítás, akkor hibás állapotot adtak vissza.
Illetve a nem dokumentalt (?) nullat irok ki az I/O portra, ahol CMOS-nal 0xFF-et fog.
Így van.
-
Vicces a z80ex, mert tulkeppen van benne egy sor, ahol a P/V flag-et allitja int eseten, emulalva az NMOS hibat. na, csupan ezt kellett feltetelesse tenni a CPU tipusatol fuggoen, illetve ez az 0xFF out 0 helyett. Ha mas nincs, akkor tenyleg igaz, hogy van mar NMOS/CMOS emulacio is :) A kerdes az, hogy Z180-ban is van ilyen kulonbseg, ott is van NMOS/CMOS, es a fentiek az elteresek, vagy ott nincs ilyen, es csak CMOS van pl, vagy pedig mas elteres (is?) van CMOS/NMOS kozott? Jelenleg elvileg barmilyen kombunaciot tudok emulalni, azaz NMOS Z80, CMOS Z80, NMOS Z180, CMOS Z180, persze a Z180 meg nincs igazan kesz (pl az uj utasitasok kozul csak a MULT van kesz).
-
A Z180 az már eleve CMOS-ként indult.
-
Elolvasva a leírást, abból az jön ki, hogy TRAP interruptot csinál a 0000h címre, ha nem definiált opcodot talál. Ahol van rá lehetőség, hogy utasításkészlet bővítést helyezzünk el.
-
Hmm, biztos? En is olvastam, most hogy igy emlitetted, rakerestem a trap szora a pdf-ben. Ugye atlag programokban nem ritka annyira az IXY/stb hasznalata, a legtobb bajt gondolom ez okozza Z180-on. Amde, ha igaz lenne, hogy ilyenkor Z180 a 0 cimre ugrik mint invalid opcode trap, akkor nem is menne a program tovabb. Marpedig amennyire remlik, a party-n a Z180-as EP-n produkalt par program fura dolgokat (sajnos nem tudom mar mi es mit ...) de nem ugy tunt, hogy total beallt a cucc, ahogy gondolom kene, ha a 0-as cimre ugrik. Na mindjart irok egy programot, ami kirakja a Z80 registereket, megprobal pl egy INC IXH -t, aztan megint kirakja a registereket. En arra tippeltem, hogy ilyenkor ha a DD/FD prefix-et az adott opcode-ra a Z180 nem csinalja meg, akkor siman figyelmen kivul hagyja (mint Z80 pl ha LD A,B -t prefixalnad ...) azaz INC IXH helyett INC H-t hajt vegre.
Az eredmenyt mellekeltem, ez egy nagyon benan megirt program, de a celnak megfelel :) Kivancsi lennek, ha majd tudod valodi Z180-on futtatni, mi kulonbseg lesz Z80-hoz viszonyitva ...
-
Amde, ha igaz lenne, hogy ilyenkor Z180 a 0 cimre ugrik mint invalid opcode trap, akkor nem is menne a program tovabb.
Mért ne menne? Előbb-utóbb csak akad egy RET, ha máshol nem a megszakítási rutinban :-)
Az eredmenyt mellekeltem, ez egy nagyon benan megirt program, de a celnak megfelel :) Kivancsi lennek, ha majd tudod valodi Z180-on futtatni, mi kulonbseg lesz Z80-hoz viszonyitva ...
Majd próbálkozok, tegnap
*** Too many wires
hiba volt :-D
(Kéne már nyákot gyártani hozzá...)
-
Egyébként néztem a leírásban, hogy ki lehet-e kapcsolni ezt, de nem, ez Non maskable interrupt, és ez a legmagasabb prioritású.
-
Nullas lapon mi van a 0-as cimen normal esetben? Csak mert gondoltam h a tesztet ki kene egeszitenem azzal, hogy detektalja, ha oda kerult a vezerles. Csak nem tudom, hogy alapjaban veve mi van ott amugy ... Azert filozok ezen annyit, mert az FD/DD az ugye prefix, es nem teljesen az opcode resze, nem ugy mint a CB es ED, nem tudom, hogy z180 mit tekint akkor opcode-nak es mit nem ...
-
Nullas lapon mi van a 0-as cimen normal esetben?
Semmi, 2fh-ig szabad.
De pl sok Spectrum átírat tesz oda rutinokat, pl joy vagy billentyű figyelést, amit aztán RST 0-val hív meg.
-
Tegyél a tesztbe oda egy ugrást ami aztán kiírja, hogy 0-ra ugrás történt.
-
Ja, OK. Mellekelve, forras is. Keretik finoman kezelni, nem a kod minoseg es a rovidseg volt a fo szempontom erre :)
A lenyeg: minden teszt elott verembe benyomok egy erteket, amit a vegen ki is veszek, normal esetben nincs kihasznalva. Ha Z180 trap volt, akkor kiirja h trap, kiirja a stack-bol kivett word-ot (ami elvileg ugye a TRAP altal oda berakott PC erteke, gondolom), illetve megnezni az "alatta" levo szot (amit en nyomtam be), es oda ter vissza. Ez azert kell, mert nem tudom, hogy a TRAP Z180-on a kov utasitasra terne-e vissza (valoszinu h nem, mert ha nem ismeri az opcode-ot, nem is feltetlen tudja, hogy milyen hosszu az!), igy a teszt tovabbi resze elott lefagyna esetleg az egesz. A forras birtokaban persze finomithato a cucc, ronda az egesz :D
Persze majd lehetne nezni pl a CB opcode-ok kozotti dolgot is, hogy ott mit csinal, mondjuk ...
Kisse fajdalmas amugy ez a DD/FD prefixalt IX/IH 8 bitre bontas tema. Kar, hogy Z180-ba ez nem kerult be, imho ez az inkompatibilitas fo oka, a tobbi cucc ritkabb. A TRAP kisse ambivalens, ha itt tenyleg lesz: egyreszt jo lenne, mert lehetne emulalni oket :) masreszt viszont nehany esetben bonyolit a dolgon, foleg, ha az ember nem szamit ra.
-
Kisse fajdalmas amugy ez a DD/FD prefixalt IX/IH 8 bitre bontas tema. Kar, hogy Z180-ba ez nem kerult be, imho ez az inkompatibilitas fo oka, a tobbi cucc ritkabb.
Igen, pláne, hogy ehhez szerintem külön dolgozni kellett, hogy ne legyen benne...
Mondjuk már azt sem értem, hogy a Z80-nál ez miért nincs benne a dokumentációban?
És amikor a Zilog átvette a Hitachitól, miért nem rakták bele...
Egyébként emlékeim szerint amíg nem jött a Fenas, addig nem voltak ezek se közismertek EP-n.
-
Igen, pláne, hogy ehhez szerintem külön dolgozni kellett, hogy ne legyen benne...
Szerintem valoszinu, hogy nem ilyen egyszeru a kerdes azert. Z80-on az IX,IY "bonthatosaga" lehet nem volt a tervben, csak igy sikerult megvalositani, hogy logikusan a DD/FD prefix-ek hatasara ez tortenik, aztan kulon nem szorakoztak vele, hogy ezt eliminaljak, max nem dokumentaltak (hasonlo dolgok vannak 65xx CPU-kban is, de ott meg durvabb dolgok is). Lehet, Z180-nal nem az az oka, hogy direkt eliminalni akartak ezt, hanem, pl maskeppen dekodoljak mar az utasitasokat, ami mondjuk vmi Z180 feature-hoz kellett ezert nincs benne ott mar. Lehet, Z180 eseten pont ahhoz kellett volna kulon dolgozni mar, hogy benne legyen, elteroen a Z80-tol :) Elvegre ezt a feature-t Z80-on akar bug-nak is lehet tekinteni (ami feature hehe), es ugye kompatibilis termeknel mindig erdekes kerdes, hogy a bug-okat is kell-e implementalni.
Mondjuk már azt sem értem, hogy a Z80-nál ez miért nincs benne a dokumentációban?
Gondolom pont azert, mert nem tervezett feature, csak "igy jott ossze" :) Ezt mutatja az a teny is, hogy a Zilog sajat asm szintaxisa (miutan a 8080-at nem vittek tovabb, ha jol remlik vmi jogi problema lett volna ezzel - mondjuk _szerencsere_ azt kell, hogy mondjam, mert a 8080 asm az szerintem inkabb remalomra hasonlit) nem is "szep" ebben az esetben: mig BC az siman kettebonthato B es C neven, az IX ugye nem: nem I es X :) lesz belole, hanem IXH es IXL. Szerintem ez is mutatja, hogy erre nem gondoltak ... Aztan kesobb lett kitalalva vmi asm syntax erre is.
És amikor a Zilog átvette a Hitachitól, miért nem rakták bele...
Ez is jo kerdes. Lehet, mivel ez sose volt Zilog reszerol dokumentalva, ezert ugy tartottak, hogy ezt nem is szabadna hasznalni. Ami vegulis igaz is, lasd amikor EP "emlekiratok" kapcsan is elhangzott, hogy IS-nel volt eloiras: nem dokumentalt utasitast nem hasznalunk, hiszen oka van, hogy a gyarto nem dokumentalta. Es igazuk is lett ... Mert pl Z180 mar nincs. Ez persze nem valtoztat azon, hogy lehetne, jo lenne az .....
Mas: itt az uj teszt, sajnos most epp kiprobalni emun se tudtam :D szoval vagy mux, vagy nem. Van benne meg ket tesztelt opcode, ED-s es CB-s opcode-okbol.
update: volt egy hiba a test programban. Inkabb innen: https://raw.githubusercontent.com/lgblgblgb/xep128/master/doc/z180test.asm
Ez mar kiir egy "M" nevu cuccost is. Ez nem register, hanem egy byte a memoriaban, amit az egyik teszt allit, a set 6,(iy+0)->a konkretan. Ebben mar a Z180 trap detektalas is benne van, mint irtam, azt, hogy mukodik-e persze nem tudom :)
-
Megneztem a neten keresgelve Z180 emulatorokat. Haaaaat :) Eleg nagy a szoras, ugy latom abban sincs egyetertes, hogy mi az invalid opcode es mi nem (ami ugye nekem is kerdes), lesz-e trap adott esetben vagy nem. Plusz altalaban addig jutnak, hogy loggoljak/kiirjak, hogy invalid opcode oszt' csok, trap stb emulacio az nuku. Szoval erdemes lenne majd megcsinalni normalisan, mert eleg gyer a felhozatal, ugy tunik :) Es igy puskazni sem tudok masrol :)
-
Zozo, hogy is van az EXOS-odban? Alapbol a Z180 0-3F portokon figyel sajat celokra, ugye? Ha jol remlik EXOS 2.3-ban (2.4?) te ezt elmozgatod, hogy EXDOS-szal ne utkozzon. A kerdes, hogy hova! 40h-rol kezdve cimre, vagy C0h-tol? Gondolom a 80h nem focizik, mert akkor ugrana a Dave/Nick :D Most ez azert kell, mert a teszt programomat tovabb finomitanam, hogy kiirja a Z180 ITC (Interrupt-Trap control) port erteket is, ha trap-ra kerul a sor, hatha abbol is ki tudunk vmit kovetkeztetni (kozben ui olvasom a Z180 leirasat, es eppen ezt talaltam hasznosnak meg!). Ha jol latom emulatorom outputjabol 0x40-tol rakod, legalabbis a 0x3f portra ez megy ki, felso ket biten. Igazam vagyon?
A masik: azt latom, hogy Z180 akkor reagal csak belso portjaira, ha a 8 felso bit nulla az I/O cimnel. Itt, ha jol kombinalok nincs a Dave "elrontja a 16 bites I/O-t" eset, mivel a Z180 belso portjait meg persze a Dave elott "sajat magaban" latja mar eleve.
-
Igen 40h-re. (A Spectrum emu, ill. az órakártya programjában kell majd ezzel foglalkozni, vagy arrébb rakni őket :-) )
-
Koszi. Na most (sjasm 0.42-vel fordul pl):
https://raw.githubusercontent.com/lgblgblgb/xep128/master/doc/z180test.asm
Hat, nem tudom, lefordul, de hogy ez muxik-e, vmit nem neztem-e el :) A mar leirtakon kivul az uj feature a Z180 trap beszedesebb megjelenitese (ha lesz), elvileg ezt kell majd pl latni:
XX Z180 TRAP YYYY ZZZZ
Az elejen az XX az ITC Z180 port/register erteke (7. bit a trap jelzo, de van ott az "UFO" bit-ek is pl ami lenyeges lehet), az YYYY a stack tetejen levo word, a ZZZZ pedig az a cim amit minden test elott benyomok a verembe, hogy biztosan jo helyre terjen vissza, akkor is, ha trap volt, es igy Z180 nem tudja milyen hosszu az opcode feltetlen (????). Persze minden hexa.
Ha ezt egyszer tudod tesztelni, nagyon kivancsi lennek a kimenetre, hogy pontosan miket ir ki a program egy Z180-on. A fenti cucc feltetelezi az EXOS-od altal "eltolt" Z180 I/O tartomanyt 0x40-tol.
Amit majd meg ki lehet probalni masodik korben: mi tortenik, ha az OUT (C),A -t kiveszed, azaz nem reset-eli az ember a trap bitet pl.
A vegen pedig kiirja a Z180 belso "portjainak" az erteket (felteve ha olvashato az adott cucc eppen, es nem write-only ...). Persze, ha mux egyaltalan, amit irtam :-P Kiprobalni nem tudtam most, meg "normal" Z80-on se (emulatoron marmint).
Ja, ha van barmi hiba/javaslat a programban, kerem szepen, szeretnem javitani, es a "jo" verziot fent tartani a github-on :)
-
https://raw.githubusercontent.com/lgblgblgb/xep128/master/doc/z180test.asm
Ezt mivel lehet fordítani?
Egy .COM-ot tudnál kreálni? (Gyorsan amíg még megy a drótgubanc :-D )
-
sjasm 0.42c
Gyorsan alkottam egyet, az .out lenne az a zip-ben. Mivel multkor feltoltve a forum vmi kepnek akarta ertelmezni, ha csak ugye odavagtam :)
Lehet jobb lenne, ha vmi file-ba irna az eredmenyt? Akkor egyszerubb lenne eltarolni :) Vagy az exos csatit kene atiranyitani file-ba, stb.
-
Errol jut eszembe, lehet en szurtam el vmit, de fura dolgot lattam: elkezdtem irni Xep128-ba azt, hogy Z180 kivalasztasanal ertelmezi a belso portokat. Azt latom, hogy most igy EXOS remekul atpakolja 0x40-tol a belso I/O-jat, ahogy kell. Aztan viszont visszarakja nullara?? Eh, lehet tudom miert :D 7E/7F portokat irja/olvassa a ZT, mert ott lenne az RTC. De igy szepen atpakolja a Z180 belso I/O-t "veletlenul" :) Pedig, arra is figyeltem (remelem jol remlik), hogy Z180 belsoleg 16 bites I/O-t figyel, es akkor tekinti belso cuccra, ha felso 8 bit nulla (es az also 8 bit felso 2 bitje is az, ahol eppen van neki configolva). Viszont ZT igy is rafut :-P Lehet, kene egy ZT verzio ami legalabb az RTC detektalasnal figyel erre, pl hogy 16 bites cimzest hasznaljon es a felso 8 bit _ne_ legyen nulla? Na persze akkor az 1Hz interruptban stb is, ahol olvassa (bar csak az olvasas gondolom nem gond, max hulyseget fog kiirni az idore?).
Szoval valodi Z180/EP-n nem szabad RTC-t hasznalni, meg ZozoTools-t ami detektalna :) bar gondolom feltunne, mert az EXDOS portokat is "eltakarja" utana, ha floppy-zni szeretne az ember gyereke ...
-
Ha jól nézzem, minden trapol...
[attach=1]
[attach=2]
[attach=3]
-
Lehet, kene egy ZT verzio ami legalabb az RTC detektalasnal figyel erre, pl hogy 16 bites cimzest hasznaljon es a felso 8 bit _ne_ legyen nulla?
Pont ezt emlegettem pár órával korábban :-)
Egyelőre csak az EXOS 2.4 meg az SDEXT 0.3 ami már direkt rákészült a Z180-ra :-)
ZT amúgy tele van undokumented utasításokkal is, miután felfedeztem őket, igyekeztem minél többet használni, hogy nehezítse a visszafejtést :oops:
-
Koszi! Erdekes! Ez sokat segithet normalis Z180 emulator irasaban :)
Amugy az jutott eszembe, hogy Ep/Z180 projecthez lehetne vmi EXOS modositas vagy tudomisen ami nullas lapra odarakja ezt a lekezelest. Ok, barmi felulirhatja (az IS-DOS pl szerintem imho biztosan - talan minden warm/cold reset akarmi utan ujra kene irni oda) vagy pl kilapozhatja vmi a nullas lapot, akkor gaz van, de amig nem, legalabb jo lenne vmire. Bar kerdes, mit csinaljon a cucc. Probaljon belapozni vmi ROM-ot, aztan leemulalni az opcode-ot? :D Vagy toltson szepen egy text szeru LPT-t maga ala, irja ki hogy Z180 TRAP, meg PC erteke stb, mar majdnem windows kek kepernyo feeling? :-D Akkor legalabb lehetne latni valodi hw-n is viszonylag egyszeruen, ha vmi belefut ebbe a trap dologba! A handlerben meg lekerdezheto, hogy 1-e a bit az ITC-ben a trap-re, igy talan kiszurheto, ha valami software veletlenul 0-as cimre ugrik, es csak azert kerul a trap handler-re a vezerles.
-
Pont ezt emlegettem pár órával korábban :-)
Tudom :) Csak en ugy ertettem, hogy nem lesz ora. Arra nem gondoltam, hogy pl ilyen bajt is tud okozni, hogy atcimzi :)
Mondjuk APU sincs sok :) meg, de ha emlekeim nem csalnak, ott meg 0x50-es port kornyeke lett volna, az se lesz akkor olyan jo valasztas :( Az meg tovabbra is faj, hogy eZ80 meg rosszabb, ott az egesz I/O tartomany foglalt, vagy vm hasonlo :( De errol mar volt szo. Pedig milyen utos lenne egy durvan szuper EP, eZ80-al, az meg ismeri az IXH/stb dolgokat is legalabb ... Es lehet is kapni, nem ugy mint az R800-at pl.
ZT amúgy tele van undokumented utasításokkal is, miután felfedeztem őket, igyekeztem minél többet használni, hogy nehezítse a visszafejtést :oops:
Ja, ismeros :), mint 65xx-en a nem dokumentalt utasitasok, aztan sziv vele mindenki, mert kesobbi pl CMOS 65C02 nem ismeri oket, 65C816-on meg minden opcode-nak van mar jelentese, ilyesmik.
-
Csak tudnam, miert nem talaltak ki, hogy ha mar van OUT0 meg IN0 legyen az pl, ami a Z180 belso portjait bizeralja, igy jobban compatible maradhatott volna a meglevo Z80 rendszerekkel. eZ80 detto. Bar azon mar gonolkodtam, hogyha EP-t nem is, pl SymbOS-t lehetne vmi eZ80 board-ra portolni nem is olyan draga egy.
Zozo, pontosan milyen Z180 van az EP-ben? Foton sajnos nem tudom kiolvasni. Csak azert kerdem, mert pl irnak ilyet pdf-ben, hogy van clock/2 enable/disable beallitas
"CPU Control Register (CCR: 1FH) (Z8S180/L180-Class Processors Only)"
Bit 7 Clock Divide R/W 0 / 1 = XTAL/2 / XTAL/1
Vagy ez nem az az osztas, amit emlitettel, hogy problemat okoz, amikor meg a Nick is "torzitgatja" az orajelet?
-
Ha jól nézzem, minden trapol...
Az utolsó képen csak azért nem volt rajta, hogy Stupid Z180 test from LGB, hogy LGB nehogy megsértődjön? :D
-
Az utolsó képen csak azért nem volt rajta, hogy Stupid Z180 test from LGB, hogy LGB nehogy megsértődjön? :D
Hat mivel en irtam a kerdeses programot, ami ezt kiirja, nem hinnem, hogy megsertodnek a sajat kiirasaim miatt :)
https://github.com/lgblgblgb/xep128/blob/master/doc/z180test.asm
-
Zozo, pontosan milyen Z180 van az EP-ben?
Most éppen S180, ezen be lehet állítani, hogy ne felezett sebességgel fusson (az aktuális EXOS ROM meg is teszi).
Vagy ez nem az az osztas, amit emlitettel, hogy problemat okoz, amikor meg a Nick is "torzitgatja" az orajelet?
De ez az, gondolom a Z180 módra lefelezett órajelet szorozza vissza, és így lesz az eredeti kimaradásból nagyobb.
(Ha szerkesztéssel írsz új kérdést, akkor azt nem veszem észre, amíg más nem ír a topicba megint :oops: )
-
(Ha szerkesztéssel írsz új kérdést, akkor azt nem veszem észre, amíg más nem ír a topicba megint :oops: )
Ebben igazad lehet, csak kicsit lelkiismeret-furdalasom van a szokasos grafomaniam miatt, es nem akarnek meg 40db post-ot irni, helyette szekesztek :) Bar, egyet irhatnek, ez igaz, akkor legalabb feltunik :)
-
Miért nem törekszünk, hogy egy erős és kompatibilis Z80 processzor?
_-----------------------------------------
Why don't we aspire to a more powerful and compatible Z80 processor?
http://opencores.org/project,a-z80
-
Ez R800 (http://Ez R800 Úgy tűnik, nagyon kompatibilis) Úgy tűnik, nagyon kompatibilis:
------------------------------------
This R800 (https://en.wikipedia.org/wiki/R800_(CPU)) seems very compatible:
Compatibility
In order to preserve software compatibility with old MSX software, the R800 uses a superset of the Z80 instruction set. In addition to all the Z80 opcodes, two multiplication instructions were added, MULUB (8-bit), and MULUW (16-bit). Also, many of the undocumented Z80 instructions were made official, including all the opcodes dealing with IX and IY as 8-bit registers (IXH, IXL, IYH, IYL).
As the R800 is not based directly on the Z80, but stems from the Z800 family, it lacks some of the other undocumented Z80 features. For instance, the undocumented flags represented in bits 3 and 5 of the F register don't assume the same values as in Z80 (causing it to fail ZEXALL tests) and the undocumented opcode often called SLL is replaced by another undocumented opcode called TST.
-
Csak nem kapható...
------
Just you can't buy it.
-
Igen, az R800 igen jo valasztas lenne, ha manapsag lehetne kapni :) A masik szemelyes kedvencem a Zilog altal manapsag is gyartott eZ80. Ez igen gyors, csomo mindent tud, stb. Az "egyetlen" problema vele, hogy az I/O tartomany mind foglalt belso celra :( Es le sem tudod beszelni errol, tehat "ki sem jon az IC-bol" az I/O keres, ha az also 256 portra vonatkozik, ami ugye nekunk pont kellene.
----
Indeed, R800 would be a great choice if it is available for sale nowadays :) My other personal favourite is the Zilog - even nowadays - manufactured eZ80. This is quite fast, with great features. There is "only" one problem. The I/O space is all used for internal purposes :( It cannot be instructed it not to do this, the I/O request is not even routed externally out of the chip, if it refers for the lower 256 I/O ports, what we would need.
-
Csak nem kapható...
------
Just you can't buy it.
Használtan sem lehet beszerezni valahogy próbából egyet...?
-
Használtan sem lehet beszerezni valahogy próbából egyet...?
Megprobaltam e-bay-en rakeresni, de ott se leltem :( Elvileg talan MSX turbo vagy milyen gepekben volt ilyen, de szerintem kb Japanban csak.
-
Talán Pear tud Xilinx-et programozni A-Z80 (http://opencores.org/project,a-z80)-nal, hogy Enterprise-szal is működjön.
-------------------------------------------------------------
Maybe Pear can program a Xiling with the A-Z80 (http://opencores.org/project,a-z80) and suit it to the Enterprise needs.
-
Talán Pear tud Xilinx-et programozni A-Z80 (http://opencores.org/project,a-z80)-nal, hogy Enterprise-szal is működjön.
Lehetne, ott a T-80 hasonlo project is pl. Sot, egesz Enterprise-t is lehetne FPGA-ban csinalni, ami igy nem emulacio, hanem hardware lenne (elvileg akar ugy is, hogy FPGA labaira ra lehetne tenni barmit, amit valodi EP-n a bovito buszra, mert hat ez hardware, nem egy software emulacio - ez utobbi eseten max az a gond, hogy az FPGA-k jellemzoen nem 5V-os TTL logikai szintekkel dolgoznak, szoval szint illesztes kene). Nemsokara lehet, lesz egy FPGA board-om, ha tul sok idom lesz, biztos megprobalom :) Az mas kerdes, hogy szerintem legalabbis Pear project-eiben CPLD van, ehhez ugye mar FPGA kene.
---
It can be, there is another similar project, the T-80. Moreover, you can create a whole Enterprise inside an FPGA, the result would be a hardware and not a software level emulation (in theory, it's even possible to connect anything onto the pins of the FPGA, what is possible to be connected onto the bus connector of a real Enterprise, after all, this is hardware and not emulation ... the only problem would be that FPGAs "typically" don't use the 5V TTL logic levels, so level converters would be needed). Soon, probably I get an FPGA devel board, if I have too much spare time, I will try it, anyway :) It's another question, that - at least IMHO - Pear uses CPLDs in their projects, but FPGA is needed for a task like these.[/quote]
[/quote]
-
I prefer CPLD, because they work immediately after power-up.
FPGA must first load a structure from external memory.
In return, they work faster, so if necessary, it must be.
I also willingly would see this project in action.
-
I prefer CPLD, because they work immediately after power-up.
FPGA must first load a structure from external memory.
In return, they work faster, so if necessary, it must be.
I also willingly would see this project in action.
Surely (and you know these better than me, that's another point here), but CPLDs are usually not "large" enough to be able to contain a whole synthesized Z80 (not even mentioning a whole Enterprise-128 in once). At the other hand, even "very old" and cheap FPGAs (like the Cyclone II from Altera, something like $10 for an old and small devel board) can be used as Z80 with some additional functions as well, behaving a computer, basically: http://searle.hostei.com/grant/Multicomp/index.html A more decent FPGA would be able to do much more than this cheap old one, that's another thing important to be noted :)
-
Gondolkodom (ábrándozás) egy kis lapon (?), amelyet az EP-ben lévő igazi Z80 helyett lehetne csatlakoztatni a géphez.
Egy gyors emulált Z80 független az alaplapi órajeltől (?). Ez más Z80 alapú gépekkel is működne ...
---------------------------------------------------------
I am thinking(dreaming) on a little board that could be connected instead of a real Z80 inside the Enterprise.
A fast emulated Z80 independent of the boards clock. It would suit also other Z80 based computers...
-
There are FPGAs, like LatticeXP2 (http://www.latticesemi.com/Products/FPGAandCPLD/LatticeXP2.aspx), that have internal Flash storage, so they can also be "instant on" devices. Or, if there is no need to update the firmware, there are one time programmable FPGAs, too. AFAIK.
Szerk.: Amilyen bamba vagyok, csak most vettem észre hogy ez egy magyar nyelvű téma. Akkor legyen itt magyarul is.
Léteznek FPGA-k, mint például a LatticeXP2, amik rendelkeznek belső flash tárolóval, így ezek is képesek "azonnal bekapcsolódó" eszközök is lenni. Vagy – ha nincsen szükség a firmver frissítésére – léteznek egyszer programozható FPGA-k is. Már amennyire jól tudom.
-
There are FPGAs, like LatticeXP2 (http://www.latticesemi.com/Products/FPGAandCPLD/LatticeXP2.aspx), that have internal Flash storage, so they can also be "instant on" devices
Maybe, I don't know honestly. However, since "plugging an FPGA" into the Z80 socket would need some daughter-board anyway (eg for logic voltage level shifting, and to bridge the different socketing, for sure), so it won't hurt too much to have some kind additional parts for the FPGA bitstream and maybe a low-performance low-pincount MCU to do the job. In SMD form, these are almost nothing. AFAIK, there are FPGAs from Atmel (hmmm, now Microchip?) combining flash and some MCU core as well, in addition of FPGA.
Or, if there is no need to update the firmware, there are one time programmable FPGAs, too. AFAIK.
I don't know, there can be ASICs for a given purpose but those are very expensive to produce (though probably one-time price, the mass production is quite cheap after that) with a price tag like 100000$. But for true FPGAs with OTP feature ... I don't know ... And it also closes the possibility to "bug fix" something later (though that's true for ASICs as well).
But please note, that I am really not an experienced one in this topic ... Just I would like to be :D
-
Maybe, I don't know honestly. However, since "plugging an FPGA" into the Z80 socket would need some daughter-board anyway (eg for logic voltage level shifting, and to bridge the different socketing, for sure), so it won't hurt too much to have some kind additional parts for the FPGA bitstream and maybe a low-performance low-pincount MCU to do the job. In SMD form, these are almost nothing. AFAIK, there are FPGAs from Atmel (hmmm, now Microchip?) combining flash and some MCU core as well, in addition of FPGA.
I don't know, there can be ASICs for a given purpose but those are very expensive to produce (though probably one-time price, the mass production is quite cheap after that) with a price tag like 100000$. But for true FPGAs with OTP feature ... I don't know ... And it also closes the possibility to "bug fix" something later (though that's true for ASICs as well).
But please note, that I am really not an experienced one in this topic ... Just I would like to be :D
Yes, of course. It depends on which solution, single OTP FPGA or FPGA+MCU+Flash, meets board-space constraints better.
It was not by a mistake that I didn't mention custom ASIC at all, I too heard about the magnitude of cost of such solutions. And I explicitly mentioned that OTP FPGAs can be considered only when it is sure that the design is complete and free of error up to a generally usable level. Meanwhile I also found this (http://www.microsemi.com/products/fpga-soc/antifuse-fpgas/mx-fpga).
You're not the only one lacking experience in this field. But there's a Hungarian guy who recently made a TED 7360/8360 (Commodore 264 series main system IC) replacement in FPGA. Maybe he could give some advise.
És most magyarul is:
Természetesen igen. Attól függ, hogy melyik megoldás – egyetlen OTP FPGA vagy FPGA+MCU+Flash – illeszkedik jobban a NYÁK terület kötöttségekhez.
Nem tévedésből nem említettem egyáltalán az egyedi cél ICket, én is hallottam az ilyen megoldások költségének nagyságrendjéről. És külön kiemeltem, hogy OTP FPGA-kat csak akkor lehet fontolóra venni, amikor bizonyos hogy a dizájn teljes és az általános használat szintjén hibamentes. Időközben még ezt is találtam.
Nem te vagy az egyetlen akinek nincs tapasztalat ezen a téren. Azonban van egy magyar ürge, aki nemrégiben készített egy TED 7360/8360 (a Commodore 264-es sorozat rendszer IC-je) helyettesítőt FPGA-ban. Talán ő adhatna tanácsot.
-
Yes, of course. It depends on which solution, single OTP FPGA or FPGA+MCU+Flash, meets board-space constraints better.
It was not by a mistake that I didn't mention custom ASIC at all, I too heard about the magnitude of cost of such solutions. And I explicitly mentioned that OTP FPGAs can be considered only when it is sure that the design is complete and free of error up to a generally usable level. Meanwhile I also found this (http://www.microsemi.com/products/fpga-soc/antifuse-fpgas/mx-fpga).
I see. Then it is my fault that I haven't even heard about OTP FPGAs, nice to know. Looks interesting, thanks. However I feel, that it's more important than to do the right think, and no need later for "firmware upgrade" as it's wouldn't be possible then :D Of course the same is true for ASICs as well. These FPGAs are not so "big" at the other hand, I have no idea what can be the smallest synthesized Z80 in term of logic cells, gates (it's not the same as the "transistor count" of a real Z80 of course, the situattion is bit different), or whatever.
Actually an FPGA implemented Z80 can be useful for some "scary" things, ie to provide RAM expansion right at the "CPU FPGA board" level. Since EP128 only "shares" the VRAM and other RAM is accessed only by the CPU, you can have all the RAM other than VRAM private to the CPU (though then you must "cache" writing of 0xB0..0xB3 I/O ports to have your own idea how segment/page "mapping" should be done). Maybe that's an odd idea, but with this, in theory it's possible to get insane CPU performance when only the "normal" RAM is needed, and "slowing down" is only needed if external I/O ports OR memory (I mean VRAM here now) access is needed (and still you can have an internal "shadow copy" of VRAM and serve _read_ requests by CPU from there on full speed, and only slow down on writes). Of course only, if it makes sense, ie it can give faster RAM than through the rest of the machine. Basically AFAIK (!!!) SuperCPU for Commodore 64 works like this: if its internal memory expansion is referred it can go near to 20MHz (?) and only there are problems when the "legacy" memory is needed to be accessed within the C64 (but SCPU is a complex topic, it uses tricky caching etc to try to reduce the number of these cases).
it's another question if it makes sense at all, or again, I have quite insane and "too futuristic" ideas, especially of kind, I wouldn't be able to realize either :) Also, even if it's sane idea for somebody, these theory should be made optional, since these ideas mess up the timing some software expects, or anything ... I just thought, if C64 (and C128 too) can have SCPU, why not having something similar for EP (though the idea is not very same, as SCPU uses a "real" 65816 CPU, and we talk here about the FPGA realization of a Z80 or something like that at least). Anyway, I like to dream :-D Greatings from the wanabe FPGA expert (so in English: not at all expert) :D[/quote]