Enterprise Forever
:HUN => Hardver => Topic started by: lgb on 2006.January.04. 09:31:37
-
http://www.zilog.com/docs/z80/comparison.html
32bites Z80? Ilyenrol eddig nem is hallottam. Ez a Z380 ez tenyleg egy letezo cucc? :) Z8000 meg Z80000 az remlik, de ez a Z380 ez miez? Akkor johet a 32 bites EP? :)
-
Valaha létezett cucc :(
kb 5 éve még fent volt a Products oldalukon. Akkoriban álmodoztam is 32 bites EP-rõl :)
-
Valaha létezett cucc :(
kb 5 éve még fent volt a Products oldalukon. Akkoriban álmodoztam is 32 bites EP-rõl :)
Én úgy látom, hogy még lehet kapni ilyet Z8038018FSC néven, google keresés alapján. Ja és most is létezik a Products oldalon csak máshol: Z80380 (http://www.zilog.com/products/partdetails.asp?id=Z80380)
-
Hmm tényleg, csak nem a prociknál van!
http://www.zilog.com/products/partdetails.asp?id=Z80380
A leírás alapján elég dögös :-)
-
A leírás alapján elég dögös :-)
Akkor indulhat a következõ fejlesztés? :wink:
-
Volna egy kérdésem. A Z80 esetében a memóriacímzés mûködését már ismerem, viszont az Input/Output utasításokat hardwer szinten hogyan hajtja végre?
Ugye 16 címvezeték és 8 adatvezeték van a processzoron. Az In Out utasítással pedig csak 8bit címezhetõ és 8 bit olvasható v. írható. Ezt akkor hogyan teszi?
-
Ugye 16 címvezeték és 8 adatvezeték van a processzoron. Az In Out utasítással pedig csak 8bit címezhetõ és 8 bit olvasható v. írható. Ezt akkor hogyan teszi?
Úgy, hogy az IN/OUT is 16 bitet címez :-)
Az utasításban megadott cím lesz az A0-A7, az A8-A15 pedig:
- IN A,(n); OUT (n),A esetén az A regiszter tartalma
- IN r,(C); OUT (C),r esetén pedig a B regiszter tartalma.
EP-n csak a 8 bites címzést használják a hardverek, viszont Spectrumon minden hw használja a 16 bites címzést.
EP-n bonyolítja a dolgot a DAVE, amin átmegy az A14,15, így ezek tartalma a belapozott szegmensek számától függ. Ezért is volt gyárilag hw hibás a Spectrum Emulátor kártya, mert ezt nem vették figyelembe.
-
Akkor ezek szerint az A15-A0 alsó 8 bit az IO cím a felsõ 8 bit pedig az adat.
1. Akkor ezek szerint a D0-D7-et IO hívás esetén nem használja?
2. Hogyan jelzi a perifériáknak, hogy ez most egy IO hívás?
A DAVE-es dolgot nem értem. Milyen probléma adódhat abból, hogy a DAVE-en keresztül megy két címvezeték, és hogy jönnek ide a szegmensek? Kérlek magyarázd meg kicsit bõvebben!
Annyit tudok, hogy a CPU a szegmensek közül a B0-B3 portokon keresztül utasítja DAVE-et, hogy melyikre melyiket lapozza be neki. És akkor gondolom, hogy ezek után, memóriacímzéskor A15-A14 címvezetékeken jelzi a DAVE-nek, hogy melyiket óhajta ebbõl 4 szegmensbõl.
-
Akkor ezek szerint az A15-A0 alsó 8 bit az IO cím a felsõ 8 bit pedig az adat.
1. Akkor ezek szerint a D0-D7-et IO hívás esetén nem használja?
Nem így van, használja a D0-D7-et az adathoz, az A8-A15 pedig a Zozosoft által leírt módon vagy az A, vagy a B regiszter tartalma. INI/INIR/IND/INDR esetén a B csökkentés előtti, OUTI/OTIR/OUTD/OTDR esetén pedig a csökkentés utáni értéke kerül az A8-A15-re. IN A, (n) utasításnál természetesen az A I/O művelet előtti értéke kerül a címbusz felső 8 bitjére.
De ennek EP-nél nem sok jelentősége van, mert a Spectrum emulátor kártyán kívül semmilyen hardver nem használja a felső 8 bitet. Csak Spectrum és CPC programozásnál fontos.
2. Hogyan jelzi a perifériáknak, hogy ez most egy IO hívás?
A Z80-nak van egy /IORQ lába (a 20.), amelynek az alacsony szintje jelzi az I/O műveletet.
A DAVE-es dolgot nem értem. Milyen probléma adódhat abból, hogy a DAVE-en keresztül megy két címvezeték, és hogy jönnek ide a szegmensek? Kérlek magyarázd meg kicsit bõvebben!
Mint említettem, EP-n az I/O portoknál semmilyen gyakorlati jelentősége nincsen, ha nem akarsz Spectrum emulátor kártyát programozni.
-
A DAVE-es dolgot nem értem. Milyen probléma adódhat abból, hogy a DAVE-en keresztül megy két címvezeték, és hogy jönnek ide a szegmensek? Kérlek magyarázd meg kicsit bõvebben!
Annyit tudok, hogy a CPU a szegmensek közül a B0-B3 portokon keresztül utasítja DAVE-et, hogy melyikre melyiket lapozza be neki. És akkor gondolom, hogy ezek után, memóriacímzéskor A15-A14 címvezetékeken jelzi a DAVE-nek, hogy melyiket óhajta ebbõl 4 szegmensbõl.
Z80 A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15
16K cimtartomány / lapok 0.1.2.3
szegmens szám SZ0 SZ1 SZ2 SZ3 SZ4 SZ5 SZ6 SZ7
EP 22 bites cimtartománya
Z80 A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 SZ0 SZ1 SZ2 SZ3 SZ4 SZ5 SZ6 SZ7
EP A14 A15 A16 A17 A18 A19 A20 A21
Az DAVE nél van a probléma /hiányosság/ az IORQ esetén is az A14 és A15 vonalon a szegmens szám SZ0 és SZ1 jelenik meg nempedig a Z80 A14 és A15 jele emiatt van a HW probléma a spektrum emulátorral.
-
Mi lenne ha külön kezelné a Z80 a program és az adatmemóriát?
Nem szállna el olyan könnyen a rendszer. Másrészt a Z80 II-ben már jó volna egy csokor lebegôpontos számláló egység is.
Természetesen Risc processzor lenne, mert csökkentett utasításkészlettel gyorsabban dolgozna.
Jó volna ha lenne direkt memória hozzáférés a perifériák felôl, a gyorsabb adatátvitel miatt (pl. LAN) de erre az esetre ki kellene dolgozni egy belsô Cache memóriát a Z80 II-be, ami lehetôvé teszi, hogy a várakozás idôszakában ne álljon a processzor.
Programozási szempontból támogatnám, hogy a processzor ugyanolyan órajelen járjon, mint a rendszermemória, szerintem az a szerencsés, ha a memóriára sosem kell várni. (kivétel a perifériá kérést, de addigott a cache)
Esetleg finomságként bekerülhetne még egy mag. Legalább a programozóknak jutna egy kis izgalom is, hiszen két magból ügyesen egyre többmindent ki lehetne hozni.
Ki mit javasol még?
-
Nem szállna el olyan könnyen a rendszer.
Szerintem az EP amúgy sem szállt el túl gyakran. De lehet, csak a Windows óta érzem így. :D
-
Mi lenne ha külön kezelné a Z80 a program és az adatmemóriát?
Az nem Z80 lenne :-)
-
Mi lenne ha külön kezelné a Z80 a program és az adatmemóriát
Szegény Neumann János forog a sírjában... :)
És akkor nem is lehetne futás közben módosítani a (gépi kódú) programon?
-
Az nem Z80 lenne :-)
Z80 II +
:D
-
Szegény Neumann János forog a sírjában... :)
És akkor nem is lehetne futás közben módosítani a (gépi kódú) programon?
Neumann talan tulelne, elvegre a Harvard architektura pont ilyen, amit sok uC is hasznal pl (mondjuk a PIC). Amugy pl egy modern x86-os CPU-ban (vagy lehetne mas peldat is hozni persze) 4K meretu lap szintjen lehet dolgokat szabalyozni. Nyilvan a Z80-nak nincs eppen fejlett MMU funkcionalitasa, de az is megoldas lehetne, ha nem csak "lapozni" lehet a 4db 16K-s "szeletet" a Z80 cimtartomanyanak a Dave 4 regisztere segitsegevel, hanem pl az is megadhato lenne, hogy read-only vagy read-write ...
Amugy meg a Z80 kapcsan: lehet az eZ80-al kene foglalkozni, ma is kaphato, 50Mhz orajelen is elmegy, es mivel azonos orajelen kb 4x gyorsabb mint az eredeti Z80, egy ilyen ugy erzodne mint "egy 200MHz-es Z80" ... Ami azert szep fejlodes :)
-
Az a baj, hogy ez a EZ80-at nehéz beszerezni.
Valami olyan RISC CPU-t kellene találni az EP II megvalósításához, amit most dögivel gyártanak, és tök olcsó. Néha bizony megéri egy rendszert egy alkatrész köré tervezni, mert olcsóbban kijön az ember. Kivéve, ha a tervezés kerül sokba, de itt most ez nem áll fenn, mert jó mérnökeink vannak, akik szívesen dolgoznak a jó ügyért :)
-
Még volna itt valami. Lehet hogy félreértettelek téged LGB, de azt tudnod kell, hogy a 386-os prociktól felfelé MINDEN alkalmazásnak (programnak, processznek) 4GB memória állt rendelkezésre, mert a processzor ennyit tudott megcímezni. Nem volt szükség lapozásra. Azért mondom, hogy mindegyik programnak (processnek), mert képes volt elszeparálni egymástól a memóriaterületeket, és ami A programnak 0x00ba13A2h memóriacímen található információ az B proginak már teljesen más értéket adott ki ugyanazon címen, nyilván azért, h. ne láthassák egymás adatait, mert akkor ha képes felülírni, beláthatatlan hibához vezet. Itt viszont már beszélhetünk "lapozásról" amikor az OP rendszer átadja mondjuk 100us idõre a másik alkalmazásnak az irányítást, akkor a neki megfelelõ memóriakörnyezetet is felépíti.
- Mielõtt belekezdek szeretném kiemelni, hogy a Win95/98 másképp mûködött mint a Windows NT, az elsõ DOS alapú volt nem volt benne igazi újítás, nem foglalkozok vele. Láthatjátok is, hogy amint lehetett számûzték, és minden mostani Windows-os OP rendszer NT alapú
Szóval, mivel akkor még nem volt ennyi (4GB) EDO-RAM elérhetõ ezért a Windows NT virtuális memóriát használt, amit a merevlemezen tárolt. És amikor a program hozzáférést kért ehhez a memóriához, azon belül pedig ahhoz a részhez, ami éppen nem volt a RAM-ban, az Operációs Rendszer betöltötte a merevlemezrõl a rendszer-memóriába amire éppen szüksége volt. Ezen kívül a felsõ 2GB-ot úgy emlékszem nem is használta, a kompatibilitás miatt, ugyanis léteztek olyan processzorok, amik a 2GB feletti részt nem támogatták (DEC alpha (http://en.wikipedia.org/wiki/Dec_Alpha))
Természetesen nem volt olyan program, ami lefoglalt volna ilyen tetemes mennyiségû memóriát, így sosem volt kihasználva teljesen.
Mindezeket csak azért tudom, mert most tanulok Windows-NT-t programozni, és a memória lefoglalás esetén fontos, hogy átlássuk a mûködést.
Egyébként mindez a finomság arra jó, hogy párhuzamosan futhasson több alkalmazás anélkül, hogy egymást zavarnák.
-
Szerintem az EP amúgy sem szállt el túl gyakran. De lehet, csak a Windows óta érzem így. :D
Nálam sûrün elõfordult.
:oops:
Egy kis végtelen ciklus, ami becsúszik, vagy a PC adatterületre állítása és annyi.
Még számtalan lehetõség kényszeríthet arra, hogy a reset gombhoz kelljen nyúlni.
:mrgreen:
-
Még volna itt valami. Lehet hogy félreértettelek téged LGB, de azt tudnod kell, hogy a 386-os prociktól felfelé MINDEN alkalmazásnak (programnak, processznek) 4GB memória állt rendelkezésre, mert a processzor ennyit tudott megcímezni. Nem volt szükség lapozásra.
Ezt rosszul tudod. Csak eppen mas fajta lapozas, nem ugyanaz nyilvan mint amit az EP a Dave-ben csinal :) A 386-os maga kozvetlenul meg tud(na) cimezni 4Gbyte memoriat igen, de az un virtualis cimtartomany ennel joval nagyobb, mivel egy lapot lehet jelolni nem letezonek is. Plusz, mivel 4Gbyte memoria ritkan volt azert 386-os rendszerben meg, eleve ezt csinaltak, ez az un swapping megvalositasanak a hw alapja, akkor egy nem letezonek jelolt lap hatasara kivetel generalodik, amit az OS lekezel, es pl a disk-rol betoltodik az aktualis lap. Nem tudom miert irod, hogy 386-oson nincs szukseg lapozasra: pont az a lenyege, minden modern OS, modern CPU-n lapozast hasznal! Csak eppen lehet, belekeveredtel a fogalmakba, mert - ahogy irtam - ez a lapozas _NEM_ az a lapozas, ami EP-ben van! Ez kis felreertesre adhat okot.
Itt jon a kepbe, hogy nem akartam azt mondani, hogy implementalni kene elsore egy "advanced MMU" (a "386-os ertelmeben vett" lapozassal egyutt) jelleget, azert mondtam, hogy mar az is elorelepes lenne, ha csak az EP ertelmben vett lapozasnal egy-egy 16K-s szeletre remondhatnad, hogy a CPU szamara az read-only, igy nem tudod felulirni veletlenul legalabb. Ettol persze ez teljesen mas jellegu dolog, mint 386-oson, ahol egy lapra azt mondod, hogy read-only, azon kivul, hogy a fogalom hasonlit, teljesen mas implementaciorol van szo, termeszeten!
Azért mondom, hogy mindegyik programnak (processnek), mert képes volt elszeparálni egymástól a memóriaterületeket, és ami A programnak 0x00ba13A2h memóriacímen található információ az B proginak már teljesen más értéket adott ki ugyanazon címen, nyilván azért, h. ne láthassák egymás adatait, mert akkor ha képes felülírni, beláthatatlan hibához vezet. Itt viszont már beszélhetünk "lapozásról" amikor az OP rendszer átadja mondjuk 100us idõre a másik alkalmazásnak az irányítást, akkor a neki megfelelõ memóriakörnyezetet is felépíti.
Ez igy nem teljesen korrekt, nem epiti fel, csak hasznalja. Az kisse "draga" lenne, ha a laptablakat ujra kene epiteni minden context switch-nel :)
En pont errol beszeltem, hogy alapvetoen azert nem kene elsore egy uj 386-ost tervezni Z80 utasitaskeszlettel :) elsore az is jo, ha a meglevo dolgokat lehetne kisse "finomitani". Itt meg arrol van szo, hogy a Z80 alapvetoen 16 bites cimbusszal rendelkezik. Ha mindenaron - bar santito - analogiat akarunk allitani, mondhatjuk, hogy a fenti peldad igaz EP-re is: amit a Z80 lat pl a 0x3AE2 cimen, az lehet mindig mas, attol fugg, mi van oda "belapozva". Persze ismetelten: vigyazzunk ezzel a "lapozas" fogalommal, mert problema, hogy azert 386-oson ez nyilvan nem ugyanazt jelenti, mint EP-n (es persze tovabbi elteres, hogy 386-oson ez a CPU resze, EP-n pedig nem, a Z80 cimbusza 16 bites, csak epp a Dave "besegit" a hianyzo cimbusz bitek eloallitasaban).
- Mielõtt belekezdek szeretném kiemelni, hogy a Win95/98 másképp mûködött mint a Windows NT, az elsõ DOS alapú volt nem volt benne igazi újítás, nem foglalkozok vele. Láthatjátok is, hogy amint lehetett számûzték, és minden mostani Windows-os OP rendszer NT alapú
Jah, win 2000 elotti dolgok azok vegulis DOS felett futo, protected mode "shell" voltakeppen nemi GUI-val :D Utana mar NT alapokon nyugvo rendszerrol van szo, amit erdendoen szerver OS-nek fejlesztettek, es maga a kernel nem is lenne rossz (pl VMS fejlesztok is reszt vettek benne). Csak epp annak amit tud, nagyon kis reszet hasznalja ki a windows-ban ami 'felette van' es kisse tonkrevagja a koncepciot ...
Szóval, mivel akkor még nem volt ennyi (4GB) EDO-RAM elérhetõ ezért a Windows NT virtuális memóriát használt, amit a merevlemezen tárolt. És amikor a program hozzáférést kért ehhez a memóriához, azon belül pedig ahhoz a részhez, ami éppen nem volt a RAM-ban, az Operációs Rendszer betöltötte a merevlemezrõl a rendszer-memóriába amire éppen szüksége volt. Ezen kívül a felsõ 2GB-ot úgy emlékszem nem is használta, a kompatibilitás miatt, ugyanis léteztek olyan processzorok, amik a 2GB feletti részt nem támogatták (DEC alpha (http://en.wikipedia.org/wiki/Dec_Alpha))
Nem kell elmagyarazni, irtam OS-t 386-osra mar, szoval tisztaban vagyok a mukodesevel :) Amit irtal, arrol irtam fentebb: egy lapot megjelolsz nem letezonek, ez ugy muxik. Amugy az most is gond akar pl Linux alatt is, ha 4Gbyte ram-od van, mert a cimtartomanyt fel kell osztani a kernel es a userspace kozott. Ilyenkor (vagy meg tobb ram eseten) jon a kepbe pl a PAE az ujabb x86-okon, ha mindenaron 32 bites rendszer kell, ami egy ujabb absztrakcios reteget jelent a cimlekepezesben valojaban.
Természetesen nem volt olyan program, ami lefoglalt volna ilyen tetemes mennyiségû memóriát, így sosem volt kihasználva teljesen.
Mindezeket csak azért tudom, mert most tanulok Windows-NT-t programozni, és a memória lefoglalás esetén fontos, hogy átlássuk a mûködést.
Vannak azert erdekes kerdesek minden OS eseten, pl memory overcommit stb, engedjunk-e tobb memoriat foglalni mint a fizikai rendelkezesre allo (hisz az valoszinu eleg durva swapolast - melleseleg szvop-nak kell ejteni, nem en irtam el, hehe) eredmenyezne kesobb.
Na bocsi, csak azert mentem bele ilyen reszleteseggel, mert ugy erzem, felreertettel, illetve osszemostad a "lapozas" fogalmat EP es 386 kozott. Remelem sikerult tisztazni, hogy mit is akartam mondani.
-
Tisztelt Fórumozók!
Elõször is, engedjétek meg, hogy bejelentsem, sikeresen leállamvizsgáztam, mostmár hivatalosan villamosmérnök lettem.
Lenne egy kérdésem. Mire való a Z80 processzor M1 lába? Mikor aktív, meddig aktív?
-
Lenne egy kérdésem. Mire való a Z80 processzor M1 lába? Mikor aktív, meddig aktív?
Az M1 az utasítások első byte-jának az olvasása közben (MREQ+M1), illetve megszakítás kérés elfogadásakor (IORQ+M1) aktív, a pontos időzítése megtalálható a Z80 dokumentációban (http://z80.info/zip/z80cpu_um.pdf). CBh, DDh, EDh, és FDh prefixes utasításoknál a prefix utáni utasítás byte olvasása közben is aktív az M1 (normál esetben, tehát ha nincs pl. több DDh prefix egymás után, legfeljebb 2 M1 memória művelet történik egy utasításban). Az ilyen típusú memória hozzáférésnek más az időzítése, és DRAM frissítést is végez. Ezt a fenti PDF file részletesen leírja.
-
Elõször is, engedjétek meg, hogy bejelentsem, sikeresen leállamvizsgáztam, mostmár hivatalosan villamosmérnök lettem.ig aktív?
Grats! En csak nem hivatalosan vagyok az, es mivel evek ota igy all, ez mar igy is marad :(
-
Jelzi valami a Z80-nak, hogy fogadta/kitette az adatokat az adatbuszra?
Csak azért kérdezem, mert ha késik a másik HW, akkor a Z80 rossz adatot olvas ki a memóriából, és kész a baj.
-
Jelzi valami a Z80-nak, hogy fogadta/kitette az adatokat az adatbuszra?
Csak azért kérdezem, mert ha késik a másik HW, akkor a Z80 rossz adatot olvas ki a memóriából, és kész a baj.
Nem jelzi semmi egy megadott eltelt idõtõl és ideig kell az adatnak aktív lennie. Lásd az idõzítõ diagramokat.
Ez van mikor egy nem létezõ szegmensrõl másolsz általában 0FFh lesz az érték de valamikor 07Fh.
-
Jelzi valami a Z80-nak, hogy fogadta/kitette az adatokat az adatbuszra?
Csak azért kérdezem, mert ha késik a másik HW, akkor a Z80 rossz adatot olvas ki a memóriából, és kész a baj.
Imho egy orajelvezerelt digitalis rendszerben ez az idozitesen mulik (ez a szinkron - alias orajelvezerelt - megoldas, ha pedig kulon jel kell, hogy "kesz" az az aszinkron), es nem kell jelezni semmivel. Az mas kerdes, hogy esetleg egy lassu periferia alkalmazhat trukkoket pl "megallitja" a CPU-t egy idore, ha neki nem eleg a "normalisan jaro" ido, vagy hasonlo ...
-
Igen a WAIT ha kell pár ciklus órajel
-
Igen a WAIT ha kell pár ciklus órajel
Ezt csinálja a Dave, ha engedélyezve van neki.
Amúgy manapság már nem lehet olyan lassú cuccot kapni, amihez kéne :-)
-
Egy kerdes: szokasos wikipediazgatas kozben raakadtam egy olyan CPU-ra hogy R800. Valaki tudja, hogy lehet-e ilyet szerezni, es milyen (hw illetve sw) kompatibilitasi kerdeseket vetne fel? Ui az nagyon szep benne, hogy a legtobb opcode sokkal gyorsabban vegrehajtodik (lasd pl itt (http://map.grauw.nl/resources/z80instr.php)), ami ugyanazon az orajelen is jelentos gyorsulast okozna. Gondolom hw szinten ez azert problemakat vetne fel eleve, nem lehetne csak ugy beletuszkolni egy EP-be, pont emiatt ...
-
Mikozben JS-ben Z80 emulatort probalok irni (az JSspeccy-s helyett) eszembe jutott valami, amibe kb 13 eve mar belefutottam (es ismertem is, csak eppen elfeledkeztem errol azota). Nem biztos, hogy erdekes barkinek, illetve lehet, hogy trivialis, de ha valakit esetleg erdekel: igen erdekes a DD/FD prefixek kezelese. Az ED/CB eseten pl a kov byte adott esetben azonnal fel van van hasznalva arra, hogy az utasitas dekodolva legyen. A DD/FD prefixek eseten viszont nem. A DD/FD voltakeppen total ugy viselkedik mint a NOP, azzal a hatalmas kulonbseggel, hogy - gondolom - beallit valami (internal, programozo szamara nem elerheto) flag szeruseget. Ez azert erdekes, mert pl a kovetkezo kodot ertelmezni erdekes kerdes: DD DD DD DD FD DD FD DD 67. Itt az "utolso" DD/FD beallitas gyoz, ami itt eppen a DD, tehat hexa DD 67 lesz belole, "LD IXH,A", ha minden igaz. Idozites es szinte minden mas tekinteteben a DD/FD-k teljes NOP-nak hatnak amugy. Egyetlen hatalmas kulonbseg azert van: gaz lenne, ha jonne egy interrupt kozben ... Ezert a Z80 kozvetlenul DD/FD utan nem engedi ezt meg. Tehat egy korrekt Z80 emulacio, ami visszater pl egy "utasitas" elvegzese utan, az biza DD FD utan azonnal visszater, csak beallit egy flag-et. Ha nem igy lenne, akkor a memoriat pl DD byte-okkal teleirva szepen meg is lehetne olni, mert soha nem erne a vegere :) Na persze ennek sok ertelme nincs, de szerintem erdekes.
A masik erdekesseg amit most olvastam, de lehet volt mar a forumon: a Z80-nak meglepo modon nem 8 bites az ALU-ja csak 4 ... Azaz 8 bites muveletet is "ket lepesben" vegzi el. Talan nem is csoda, hogy "lassu", mar ha modernebb Z80 kompatible implementaciokhoz kepest nezzuk. Amugy nekem mindig is gyanus volt: a 6502 emlekeim szerint vmi 3500 tranzisztorbol all, es eleg egyszeru (de logikus) cucc is. A Z80 ehhez kepest elegge komplex (bar ugyanolyan orajelen lassabb is, lasd NOP az 4 ciklus Z80-on, es csak 2 6502-n), es 8000 koruli tranyot szamlal, ami bar tobb, erzesileg megis keves. Lehet ez a 4 bites ALU pont azert kellett, mert nem fertek bele a "keretbe" maskepp? Vagy mar 8080 eseten is ilyesmi lehetett, amivel a Z80 compatible akart lenni?
Remelem nem untattam senkit (nagyon). :)
-
Beszélgetés a Z80 tervezőivel. (http://archive.computerhistory.org/resources/text/Oral_History/Zilog_Z80/102658073.05.01.pdf)
-
Szép anyag, ha valaki átrágja magát rajta, röviden elmondaná mi a story?
-
hú ezt én is el fogom olvasni
az durva hogy a z80 tudásommal 1 tap tanulás után simán kódoltam az x86-ot :)
most mai is bármelyik modern intel procit pár nap után simán kódolnám
azért ez nem semmi, hiszen egy kis pici "ósdi" prociról beszélünk
múltkor találtam egyet az utcán lomtalanításkor, azóta itt figyel az asztalomon :)
-
En elolvastam, koszi erte. A 6800 emlitese erdekes. Azert is, mert a 65xx csaladnak is van hozza koze, sot meg tobb is: a 65xx CPU-k voltakeppen akkoriban "szuper olcsoak" voltak, es a 6800 uzletet celozta meg rendesen (sikerrel). Alapvetoen egyszerubb, mint a 6800 viszont az arat is sikerult igy toredeken tartani. Programozasa meg tobb ponton hasonlit ra, sot a busz rendszeruk kompatibilis is. A Z80 es a "mai" x86 procik rokonsaga meg ugye nem veletlen, mivel a 8080-al compatible a Z80 (csak eppen erosen kibovitve), a 8086/8088 meg voltakeppen szinten a 8080-bol szarmazik (csak maradt intel), bar itt a visszameno kompatibilitas nincs meg, azert filozofiaban erosen erezheto a hasonlosag. Utana meg mar csak "kis" ugras, hogy 80286, 386, 486, pentium :) Az oskori ISA maradt, amitol nyognek is nagyokat a "modern" CPU-k, mert szamukra ez baromira nem idealis (nem RISC ISA, holott belulrol kb minden proci az, "tiszta" RISC architektura - mint pl az ARM - azert lenyegesen olcsobb/kevesebb tranyo kell hozza, es kevesebbet is fogyasztanak). Engem meglepett a Z80/6800 egy cikkben valo emlitese, es mindig is ugy tudtam, hogy a Z80 egy csomo ex-intel fejlesztomernok Zilog bereki alatt lerehozott procija, ami a 8080 (intel) piacara palyazott (mondhatni sikerrel ...).
-
Off: A Vadász Les (http://www.sg.hu/cikkek/27282/visszavonul_leslie_vadasz_az_intel_uttoroje) (Angolul Les Vadasz) nevű Inteles fickónál nem bírtam megállni röhögés nélkül :ds_icon_cheesygrin: vajon direkt poénkodott, amikor így rövidítette a nevét, mondván, hogy az amcsik úgyse értik, vagy csak így alakult, hogy ott szokás Les-nek becézni a Leslie-t?
-
Szép anyag, ha valaki átrágja magát rajta, röviden elmondaná mi a story?
A dolog onnan indult, hogy Federico Faggin, akinek a főnöke volt Vadász, nem érezte jól magát az Intelnél, nem tudta az elképzeléseit megvalósítani, mivel az Intel akkor még nem fordított elég figyelmet a mikroprocesszorokra, hanem elsősorban memória gyártó cég volt. Csak azért foglalkoztak processzorokkal, mert memóriákat és egyéb kiegészítő áramköröket lehetett eladni velük.
Ezért döntött úgy Federico Faggin, hogy saját céget alapít, ami csak mikroprocesszorokat fog gyártani, jobbakat mint az Intel. Amikor kilépett, akkor jöttek vele még ketten: Masatoshi Shima, Ralph Ungermann
-
Milyen hasonlóság érezhető a 8080 és a 8088 között? A 8085-t hova lehet rakni?
-
Milyen hasonlóság érezhető a 8080 és a 8088 között? A 8085-t hova lehet rakni?
A 8085 az csak kisebb ráncfelvarott változata a 8080-nak, a fő lényeg a szimpla +5V-os tápellátás. (Ami a Z80-nál is alap kiindulási szempont volt.) Két új utasítás van a 8080-hoz képest.
A 8088 pontosabban 8086 az egy erősen kibővített verziója a 8080-nak, 16 bitesre bővített regiszterek, szegmens regiszterek bevezetése több memória eléréséhez, több utasítás. De az alapelvek nem változtak. Forráskód szinten kompatibilisnek mondták, volt olyan compiler amivel a 8080-as forrásból 8086-osra lehetett fordítani.
-
volt olyan compiler amivel a 8080-as forrásból 8086-osra lehetett fordítani.
Ez érdekelne.
-
Ez érdekelne.
XLT86 (http://www.programmersheaven.com/download/15567/Download.aspx)
Leírás (http://bitsavers.informatik.uni-stuttgart.de/pdf/digitalResearch/cpm/XLT86_Users_Guide_Sep81.pdf)
-
Köszi. Translates Intel 8080 assembly language source code to Intel 8086 assembly language source code.
-
vajon milyen z80-as hw volt az amiből a legtöbbet eladtak? specy?
gameboy és gameboy colorban is z80 van, meg biztos van még ilyen konzol
-
Nem biztos, hogy házi számítógép lesz a vezető...
Mindenesetre ezt írták (2006-ban): I figure, because now I’m chairman of Zilog, and I
went through a little bit of data, I figured there were over two billion Z80s sold by the various sources. But
many Z80s are actually used in embedded application, so we don’t even know how many of those there
are. For example, NEC is still using Z80s in many of their embedded ASICs.
Vagyis már több mint 2 milliárd Z80 lett eladva, és nem tudni, hogy ezenfelül még mennyi Z80 van beépített alkalmazásokban, ahol CPU mag egy cél IC részeként van megvalósítva.
(És amellett, hogy a Zilognak is van sokféle továbbfejlesztett, mindenfélével egybeépített verziója, az általunk ismert klasszikus Z80 (http://www.zilog.com/index.php?option=com_product&Itemid=26&task=parts&BL=1&familyId=20&productId=Z84C00&puqs=b3B0aW9uPWNvbV9wcm9kdWN0JnRhc2s9cHJvZHVjdCZidXNpbmVzc0xpbmU9MSZpZD0xMzkmcGFyZW50X2lkPTEzOSZJdGVtaWQ9NTk=) is még gyártásban van.)
-
az durva hogy még gyártják :D
vajon miért??? gondolom csak alkatrészcsere céllal veszik...
-
gondolom csak alkatrészcsere céllal veszik...
Nem hinném, hogy csak ezért megérné gyártani. Ott a példa, hogy pár éve a NASA Ebay-en vásárolta fel a 8086-osokat az űrsiklókhoz. Ha Z80-at raktak volna bele anno, vehettek volna vadiújat :-)
-
Nem hinném, hogy csak ezért megérné gyártani. Ott a példa, hogy pár éve a NASA Ebay-en vásárolta fel a 8086-osokat az űrsiklókhoz. Ha Z80-at raktak volna bele anno, vehettek volna vadiújat :-)
haha ez vicces
lehet, hogy a NASA vette meg az összes EP-t, és semmisítette meg őket??? durva! :D
-
vajon milyen z80-as hw volt az amiből a legtöbbet eladtak? specy?
gameboy és gameboy colorban is z80 van, meg biztos van még ilyen konzol
Negativ, az nem Z80, bar hasonlt ra. Pl nincsen benne DD, FD prefix, nincs IX es IY register (es a veluk kapcsolatos muveletek), es meg par kisebb valtozas is van. Viszont "cserebe" pl van a 65xx-osokhoz hasonlo fogalom, egy 256 byte nagysagu terulet ami kulon opcode-okkal egy byte-al cimezheto (65xx-n ez a "nullas lap" bar itt FF00-n van eppen nem nullan ...), es igy nemikepp gyorsabb vele dolgozni. Ja, es nincs IN/OUT sem (gondolom itt is memoriaba agyazott I/O van, ahogy pl 65xx-n is). Mar amennyire emlekszem, sok hulysegemre jellemzo, hogy pl ilyen emulatort is akartam irni egyszer, ennyi remlik belole fejbol. Felteve, ha ez a gameboy coor tenyleg, es nem keverem valami massal :) Az biztos, hogy vmi gameboy volt az is.
Na, kozben rakerestem:
http://realboyemulator.wordpress.com/2013/01/01/the-nintendo-game-boy-1/ (http://realboyemulator.wordpress.com/2013/01/01/the-nintendo-game-boy-1/) es pl http://pastraiser.com/cpu/gameboy/gameboy_opcodes.html (http://pastraiser.com/cpu/gameboy/gameboy_opcodes.html)
-
az durva hogy még gyártják :D
vajon miért??? gondolom csak alkatrészcsere céllal veszik...
65xx-eket is gyartanak, pl 65C02 es a 16 bites valtozatat (65C816), 20MHz-en elmennek szepen, es CMOS meg minden, termeszetesen (ez 65xx-nel nagy szo, mivel ott nincs kulon m/t cycle, minden a memoriaelerest is beleertve a kulso orajelen megy, tehat 20MHz igen szep sebesseget ad egy 65xx-hez kepest ...). Gondolom hasonlo celzattal teszik, bar allitolag par design hu ceg meg mindig hasznal ilyeneket uj cuccban is, mondjuk ez nekem fura (olcsobban kap ennel joval utosebb es kevesebbet is evo CPU-kat ma mar ...).
-
bar allitolag par design hu ceg meg mindig hasznal ilyeneket uj cuccban is, mondjuk ez nekem fura (olcsobban kap ennel joval utosebb es kevesebbet is evo CPU-kat ma mar ...).
De arra újra meg kell írni a programot, tesztelni, stb. Ipari cuccoknál jó dolog a sok éve kitapasztalt megbízhatóság, és ott nincs az, hogy kijött valami programból az n+1 verzió, és 2x annyi proci kell neki, meg 4x RAM :-)
Ha jól működik valami, minek felesleges variálással elrontani :-)
-
De arra újra meg kell írni a programot, tesztelni, stb. Ipari cuccoknál jó dolog a sok éve kitapasztalt megbízhatóság, és ott nincs az, hogy kijött valami programból az n+1 verzió, és 2x annyi proci kell neki, meg 4x RAM :-)
Ha jól működik valami, minek felesleges variálással elrontani :-)
ACK. Azert irtam hogy vannak design hu emberekek/cegek ahol ez nem elhanyagolhato szempont :) Csak ugye sajna azert csak "kikopnak" ezek, total uj dolgot meg nem igazan csinalnak veluk mar :(
-
lehet, hogy a NASA vette meg az összes EP-t, és semmisítette meg őket??? durva! :D
A hír csak félig igaz. A mai napig használják őket pl. az enterprise űrhajóban.
-
na és várjunk csak! ha még használják a z80-t, akkor ezek szerint aki tudja programozni, annak ez munkalehetőség :)
-
na és várjunk csak! ha még használják a z80-t, akkor ezek szerint aki tudja programozni, annak ez munkalehetőség :)
Ez valoszinu igy van. Es mint sok "regi" technikaval, ha sikerul megtalalni egy ilyen melot (ami persze nehez, mert nem sok helyre kell ...), akkor egesz szepen lehet belole gondolom keresni, mert azert ma mar nincs tul sok ember, aki ilyesmivel foglalkozik a "huzzuk az ikont a vinyozban!" a meno mar a programozoknal is lassan ...
-
jaj már régóta az a menő kóder aki windózban tud formot csinálni és gombokat rárakni :D
sztori: első munkahelyemen mutattam a kódereknek hogy én is programoztam, mutattam nekik a tök komoly platformjátékomat, saját 2d render, marha komplex gameplay. hümmögtek.
aztán egyszer véletlen előkerült egy programom amiben egy formra raktam deplhiben pár gombot meg valami bitmapot, szöveg kiírás stb... megszólal egyik srác: "hm, te tényleg tudsz programozni"
XD
-
sztori: első munkahelyemen mutattam a kódereknek hogy én is programoztam, mutattam nekik a tök komoly platformjátékomat, saját 2d render, marha komplex gameplay. hümmögtek.
Ezeket bemutathatnád, szerintem sokunkat érdekelne a működése.
-
Ezeket bemutathatnád, szerintem sokunkat érdekelne a működése.
már hogy érted?
forrást is odaadom ha kell :) pascal+asm, illetve delphi+asm
végül is ugyanaz a 2d render mint EP-n... pixeleket rakosgat az ember marha gyorsan, még egy 20Mhz-s 286-os is elég cool volt már sebességben (meg gondolom már a memória is)
egyik játékom (mega mac man című, DOS) 320x200-as vga grafikát használt, statikus pályák (tehát nem scrollos), de marha komplex gameplay (kb boulder dash egy marha komplex verziója ötvözve platformerekkel)
a másik komolyabb csak engine szintjére ért, játék már nem készült vele, ez delphi+asm, parallax scrollos, bármennyi layer-t kezelő engine, nagyon komoly editorral. ekkor kezdtem céges szinten játékfejlesztésbe, úgyhogy ezért is hagytam abba. meg ez már olyan bonyolult volt, hogy több ember kellett volna hozzá...
-
http://www.righto.com/2014/10/how-z80s-registers-are-implemented-down.html (http://www.righto.com/2014/10/how-z80s-registers-are-implemented-down.html)
Mondjuk az infok egy reszet olvastam mar itt-ott, de azert nekem legalabbis volt ujdonsag. Erdekes olvasmany szerintem.
-
Ha valos (nem memory referesh vagy int ack) memoria vagy I/O igeny jon ki Z80-bol, akkor jol tippelek, hogy arra az idore az RD es a WR kimenetek mindig pontosan egymassal ellentetben allnak? Tehat voltakeppen akar nezhetem csak az egyiket is, ha pl RD mint low active jel low, akkor read, ha az RD magas akkor write, es ehhez a WR-t meg se kell neznem, mert csak igy lehetseges. Azert kerdem, mert van amit igy egyszerubb megoldani nekem pl, mint kulon RD-t es WR-t nezni (amugy 65xx-en pl egy szem drot, egyik jelszint WR a masik RD, nincs ket kulon laba a CPU-nak erre, egy szem van).
-
A frissitést még ugyan külön tudod választani a RFSH vezetékkel, de azt Int Ack-ot csak úgy, ha nézed a RD és WR vezetéket is az IORQ mellé. (Ez nem jött össze anno az 'a' Studiónak...)
-
A frissitést még ugyan külön tudod választani a RFSH vezetékkel, de azt Int Ack-ot csak úgy, ha nézed a RD és WR vezetéket is az IORQ mellé. (Ez nem jött össze anno az 'a' Studiónak...)
Vilagos, azert is irtam, hogy mar eloallitottam mondjuk magamnak azt az "MREQ" (nevezzuk annak pl) jelet, ami biztosan nem refresh, tehat valoban memoria muvelet, akkor az RD es WR jelek minden esetben garantaltan egymasnak tukorkepei. En csak olyantol felek, hogy van par ns keses, mert egyik jel pl tobb kapun megy at a CPU belsejeben es igy vmi hazard kepzodik, mert az RD/WR le es felfuto elei nem pontosan szimmetrikussak, meg ha "stabil" jelszintnel igaz is, hogy egymas "tukorkepi". Na, most jol elmondtam :) Amugy azert kell, mert multi-CPU (Z80, 65xx) erdeklodesem miatt arra gondoltam, hogy csinalok nemi kis "interface-t" Z80-hoz es 65xx-hez is, es kvazi uazt a hw-t akasztom ra mindkettore ezek utan, igy nem kell ketszer megcsinalni mindent a ket CPU tipushoz mondjuk :)
Viszont az IO dolgot nem ertem amit irtal. Miert kell nezni az IORQ melle az RD/WR-t is? Hiszen lehet port iras es olvasas is. Nem ugy van, hogy IORQ melle az M1-et kell nezni, hogy int ack, vagy I/O muvelet? Vagy en emlekszem rosszul? Mert akkor azt csinalnam, hogy M1 es IORQ alapjan eldontom, hogy ez "valodi" I/O muvelet (nem int ack), illetve RFSH es MREQ alapjan, hogy "valodi" memoria muvelet (es nem dram frissites), es akkor ezek utan mar igaz, hogy az RD vagy WR kozul egyik mindig aktiv, es pont egymassal ellentetes a ket jel. Vagy tevedek?
-
Errol valaki mar hallott?
https://www.tindie.com/products/microwavemont/z80-single-board-computer-version-20/
Marmint, ami erdekes benne:
"Main MCU is TOSHIBA TMP84C015, which contains Z80 CPU, Z80-CGC, Z80-CTC, two Z80-SIOs, two Z80-PIOs."
Szoval erdekes cucc lehet, van benne egy rakas minden ... Kar, hogy semmi specifikaciot nem talalok rola sehol. Idegesito, hogy gugli is rakas talalatot dob ra, adatlap itt/ott, de minden linken kb valamilyen IC kereso oldal jon be, ahol persze ott szerepel a neve, de rakattintva aztan nincs talalat, meg hasonlo ... :-/
-
http://pdf1.alldatasheet.com/datasheet-pdf/view/97567/TOSHIBA/TMPZ84C015BF-10/+75W78UPLRhpDDdXSUfGDLzwHOTOhh+/datasheet.pdf
-
Kar, hogy semmi specifikaciot nem talalok rola sehol.
Zilog oldalán nem nézted? :-) (http://zilog.com/index.php?option=com_product&Itemid=26&task=docs&businessLine=1&parent_id=139&familyId=20&productId=Z84C15)
Ma is gyártják. (http://zilog.com/index.php?option=com_product&Itemid=26&task=parts&BL=1&familyId=20&productId=Z84C15&puqs=b3B0aW9uPWNvbV9wcm9kdWN0JnRhc2s9cHJvZHVjdCZidXNpbmVzc0xpbmU9MSZpZD0xMzkmcGFyZW50X2lkPTEzOSZJdGVtaWQ9NTk=)
-
Zilog oldalán nem nézted? :-) (http://zilog.com/index.php?option=com_product&Itemid=26&task=docs&businessLine=1&parent_id=139&familyId=20&productId=Z84C15)
Ma is gyártják. (http://zilog.com/index.php?option=com_product&Itemid=26&task=parts&BL=1&familyId=20&productId=Z84C15&puqs=b3B0aW9uPWNvbV9wcm9kdWN0JnRhc2s9cHJvZHVjdCZidXNpbmVzc0xpbmU9MSZpZD0xMzkmcGFyZW50X2lkPTEzOSZJdGVtaWQ9NTk=)
Nem neztem, azt hittem ez vmi csak Toshiba cuccos, nemi Zilog licenccel gyartva, volt mar ilyenre is pelda. Az eszembe sem jutott hogy mas gyartonal keressem ....
Amugy persze meg mindig azt nezem, mit lehetne meg EP-be tenni, csak azert kerdeztem :-D
-
vajon miért lett az ep-ben a z80 4mhz-s? és miért 3.75 (vagy mennyi) a speciben?
később készült és akkor már jobb z80-ak voltak?
-
vajon miért lett az ep-ben a z80 4mhz-s? és miért 3.75 (vagy mennyi) a speciben?
később készült és akkor már jobb z80-ak voltak?
Tudtommal van Z80/A, Z80/B, Z80/C, (meg még mit tudom én mi, egyre gyorsabbak :-) ) de fogalmam sincs, akkoriban volt e már így többféle. Ha igen, akkor nem tudom, miért nem egyből a "B" -vel indítottak... (Mondjuk a tervezés időszakában a 4Mhz is untig elégnek számított. :-) )
-
vajon miért lett az ep-ben a z80 4mhz-s? és miért 3.75 (vagy mennyi) a speciben?
később készült és akkor már jobb z80-ak voltak?
Szerintem 3.5MHz a speccy. Az a 7MHz-es pixel clock fele, es idozites szempontjabol fontos - gondolom - ami akkoriban jellemzo volt a legtobb gepre (marmint: video jel eloallitas es cpu is "kuzdott" a RAM-ert, es ossze kellett hangolni). Ezert van pl, hogy a PAL es a NTSC C64 CPU frekvenciaja sem pontosan ugyanaz, mert a videojel jellemzoi is masok, amihoz "idomulni" kellett. Amugy meg az Amiga orajele is a fenti tema miatt annyia, amennyi. HA jol tudom ... 7.16MHz NTSC gepeken, 7.09MHz PAL gepeken. Vagy hasonlo.
Ebben aztan igazan nem vagyok valami nagy szakerto, de amennyire en latom, EP-nel azert erdekes ez a kerdes, mert ott nincs szo szerinti osztozas a buszrendszeren. Marmint, a video RAM, az csak a Nick "tulajdona". Az mas kerdes, hogy a CPU is elerheti, am csak a Nick-en at, kozvetlenul nem (az igaz, hogy a programozo szamara ez kvazi transzparensnek tunik, de ettol meg ami igaz, az igaz). Aztan a Nick szepen deformalgatja szegeny CPU orajelet, ha a VRAM-hoz akar nyulni (vagy Nick specifikus I/O portokhoz is). Szoval emiatt EP-n szabadabb az orajel valasztas. Talan emiatt a turbo is egyszerubben megoldhato ...
Az eredeti Z80 2.5MHz-et "birt" (a Primo orajele is ha minden igaz, mivel az egy U880 nevu - illegalis? - Z80 klont hasznalt, ami erre volt "meretezve"), a Z80A 4-et, Z80B 6-ot, a Z80H meg 8-at ("hivatalosan" ... az mas kerdes hogy allitolag azert lehet oket huzni, mondjuk gyari design-ban valoszinu hogy nem nagyon csinalnank ilyet). Amennyire tudom, CMOS technikaval gyartottaknal van mar csak (?) a gyorsabb peldanyok, ahol viszont az also frekvencia sincs limitalva (azaz "meg is allithato hosszabb idore" ha leall a clock, mondjuk ez most a tema szempontjabol tokmind1, de regebbi CPU-knal volt also freki limit is). Arrol amugy fog'sincs, hogy ezek pontosan mikor jelentek meg (az "erdeti" Z80 meg '76-ban, ha jol remlik). Az is lehet, hogy borsosabb volt az aruk is a gyorsabb peldanyoknak amugy.
Majd valaki okosabb helyesbit ha tevedek valahol a temaban.
-
Ezt én se értem, a sok késést kompenzálhattak volna egy gyorsabb géppel némileg...
Az egyértelmü, hogy terveztek 6MHz verzióra, ott a Dave-ben a beállítás. A Modell 911-et is még 4MHz-el kezdték el, menet közben tértek át 6MHz-re.
-
Lehet, hogy érdemesebb lett volna 3.56 és 7.12 MHz-es gépeket készíteni, ha a video és a CPU órajel aránya egész, az egyszerűsíti a tervezést, a video RAM és így az EP64 akár még gyorsabb is lehetett volna a bonyolult szinkronizáció nélkül, és talán nem lenne alapértelmezett M1-es várakozás sem.
-
Esetleg "belso embereink" :) nem tudnak errol a temarol infot adni? Marmint peldaul Bruce baratunk. Tenyleg fura, hogy "ott a 6MHz szinte" de nincs hasznalva alapbol. Az is lehet, hogy uzletpolitika, es akartak valamit mutatni kov verziora is, ezert nem celoztak meg a 6MHz-et mindjart?
A masik, amit Istvan mondott. Sajnos en annyira nem latom at a temat, hogy egyertelmuen tudjam, gyorsabb/hatekonyabb/egyszerubb (ezek egyike, vagy esetleg mind, stb?) lett volna a a design ha a CPU orajel a pixel clock-al valamilye viszonyban van mint a legtobb gepnel szokas? Mert en azt latom, hogy tenyleg, legtobb gepnel igy csinaljak, amde az EP-nel nem. Bar mondjuk itt van custom chip (Nick) es lehetett eleg laba :) is, stb ... Azert egy C64 VIC-II 40 labu tokba nehez lehetett volna megcsinalni azt es ugy, ahogy a Nick csinalja. Viszont nem tudom, hogy ez a "banalis" ok ez csak az en fejemben letezik, vagy van mar szempont is, hog melyik design az elonyosebb?
-
This Z80 emulation project (https://github.com/hoglet67/AtomBusMon/wiki) is very much like having the EP128emu debugging tools working on the real hardware.
I've not seen the max clock frequency reached.
-
This Z80 emulation project (https://github.com/hoglet67/AtomBusMon/wiki) is very much like having the EP128emu debugging tools working on the real hardware.
I've not seen the max clock frequency reached.
Interesting. If I see well enough, this means a CPU implemented in an FPGA (so not using a "discrete" CPU?) with additional parts for the debugging/etc.
-
Yes, the best is that the Godil devices are already build and cheap. They plug directly on the Z80 socket. You even can mount them piggy-back with the real Z80 to abduct it.
-
azon gondolkodtam, vannak-e táblázatok a z80-ban amivel számításokat gyorsítanak?
persze ami számításokat tud, azok elég egyszerűek...
-
azon gondolkodtam, vannak-e táblázatok a z80-ban amivel számításokat gyorsítanak?
persze ami számításokat tud, azok elég egyszerűek...
Mire gondolsz gyök táblázat vagy valami hasonló?
A régiekben kizártnak tartom azokban nem volt co-processor.
Ezért készült az AMDxxx matematikai proceszor illesztése.
-
Mire gondolsz gyök táblázat vagy valami hasonló?
A régiekben kizártnak tartom azokban nem volt co-processor.
Ezért készült az AMDxxx matematikai proceszor illesztése.
osztást szorzást stb nem lehet táblázattal gyorsítani?
-
osztást szorzást stb nem lehet táblázattal gyorsítani?
Természetesen lehet, de itt - ahogy olvasom - 1976-ról van szó. A Z80 nem tud szorozni/osztani. (Mármint nincs rá direkt utasítása.) Akkor az ilyen táblázatok erősen tranzisztorpazarlásnak számítottak volna.
-
Viszont nem tudom, hogy ez a "banalis" ok ez csak az en fejemben letezik, vagy van mar szempont is, hog melyik design az elonyosebb?
Ha csak 64K ram van akkor nem annyira jó lásd a Spectrum progikat valamivel lassabbak az eredetinél.
Viszont ha 128K-s a gép akkor külön-külön tud pörögni.
Így ha azokat a rutinokat amit soszor futtat nem video ramra helyezed akkor a program ellen súlyozza a lassabb részeket.
-
osztást szorzást stb nem lehet táblázattal gyorsítani?
Lehet de olcsóbb egy jó rutin mint egy plusz processzor. pláne ha egybe akarják integrálni az intel is csak a 486-os tol kezdte egyesíteni. Az meg igen csak a 80-as évek végén volt ?!?
-
Természetesen lehet, de itt - ahogy olvasom - 1976-ról van szó. A Z80 nem tud szorozni/osztani. (Mármint nincs rá direkt utasítása.) Akkor az ilyen táblázatok erősen tranzisztorpazarlásnak számítottak volna.
hm nincs szorzás? akkor biztos összekevertem az x86-al :)
ja hát táblázatokhoz mem kell, hát igen.
-
hm nincs szorzás?
Nincs, de nálunk ez nem oszt, nem szoroz.
-
Valaki fel tudna vilagositani, hogy hardware szinten hogy is van a Z80-nal az interrupt kerdese? Ugye, amennyire tudom, szint-erzekeny a bemenet (tehat nem el erzekeny). Azaz, ha ez szepen aktivra ugrik, majd vissza is, de kozben a CPU egy sok T-state-be kerulo opcode-ot hajt vegre, akkor a CPU nem fogja ezt agyaltalan eszrevenni? Magyaran: mikor tortenik a "mintavetelezese" pontosan az interrupt request bemenetnek a Z80-on belul? A kerdes Z80-only, tehat Dave stb nincs a kepben! Onnan jutott eszembe, hogy epp ZX Spectrum ugyben nezelodtem piheneskeppen, es valami olyasmi latszik (de lehet elneztem), hogy csak 16 T-state-ig aktiv az interrupt keres minden video frame-nel egyszer. Namost, mivel ha jol remlik, a Z80-on a leghosszabb utasitas tobb mint 16, elvileg elofordulhat, hogy siman nem veszi eszre az interrupt-ot, mert pont az "opcode idotartama ala" esik vegig az INT jel aktiv szintje?
-
Ha jól emlékszem, akkor a Z80 egy ciklussal az utasítás vége előtt figyeli az IRQ bemenetet, és Spectrumon 32 ciklus a hosszúsága, illetve 128K-s gépen 36.
-
Ha jól emlékszem, akkor a Z80 egy ciklussal az utasítás vége előtt figyeli az IRQ bemenetet, és Spectrumon 32 ciklus a hosszúsága, illetve 128K-s gépen 36.
32, igen, amennyire en ki tudom hamozni, de az a 7MHz-es (video) orajelben merve, azert feleztem meg, hogy a CPU "szempontjabol" (3.5Mhz) mennyi. Vagy total elnezem az egeszet :-D
-
Nem tudom, eredetileg hol találtam az információt, de az emulátorban 32/36 Z80 ciklus, a 16 nem lenne elég ahhoz, hogy megbízhatóan működjön.
-
Nem tudom, eredetileg hol találtam az információt, de az emulátorban 32/36 Z80 ciklus, a 16 nem lenne elég ahhoz, hogy megbízhatóan működjön.
Igen, ezert kerdeztem en is ... Amugy kisse ellentmondo infok vannak (soha nem volt Spectrumom, ezert leirasokbol tajekozok, meg ilyenek ...), es a leirasok - szamomra - tulsagosan "lazak", nehol nem egyertelmu stb. Szoval meguntam a dolgot, es epp egy allitolag tok megbizhato ULA-reimplementaciot nezek, marmint CPLD/FPGA-sat, pontosabban a Verilogban irodott szerkezetet, az alapjan modtam csak ezt. Engem is kisse meglepett (16 az kevesnek tunik!) eredeti kerdesemet azert is tettem fel, hatha valamit nem tudok esetleg, es kiderul, hogy egy utasitas vegrehajtasa soran tobbszor vizsgalja a Z80, tudomisen minden M-ciklus vegen, vagy pedig arrol van szo, hogy nem az opcode legvege fele, hanem elobb, es ezert a 16 eleg, stb, nem tudom ... De tenyleg csak tippelgetek. Az is lehet, rossz az alapfeltetelezes, es a kerdeses verilog kod is, vagy en nem olvasom jol :-D
Hmm. Egy dolog szoget utott a fejembe: valojaban az igazan hosszu utasitasok nem egy utasitas. Van DD/FD prefix es/vagy CB is pl, vagy ED ... Az nem lehet, hogy itt azert nincs gond, mert a prefix maga egy utasitaskent is felfoghato (tehat latch-elheti az interrupt igenyt), annak ellenere, hogy nyilvan egy prefix es utana levo cucc kozott nem fogja ettol meg vegrehajtani (az nagy baj is lenne), de latch-elve mar van. Mert ha jol nezem talan a leghosszabb utasitas Z80-on 23 orajel ciklus, nem tudom kijonne-e igy, ha figyelembe vesszuk hogy meg az utasitas kozvetlen vege elott van sampling meg _esetleg_ prefix-ek vegen is valami. No persze siman lehet, hogy eleve rossz a feltetelezesem es nem 16 ciklus (marmint CPU-nyiban merve), es az egesz hulyeseg amit itt feszegetek temat :D
Amugy ez a teora - talan - ellenorizheto lenne egyszeruen is, mert pl ugye a DD/FD prefix-ek sorozata (pl DD DD FD DD FD ....) valojaban semmi ertelmeset nem csinal, amig nem jon az elso nem DD/FD, es akkor az utolso szamit (ellenben ugye a CB/ED-vel). Most kerdeses, hogy ilyen mestersegesen elnyujtott cuccban ha kozben jon interrupt keres ami le is cseng, azt latch-eli-e a z80 es esetleg vegrehajtja miutan vege a DD/FD+opcode mizerianak ...
Kar, hogy nincs egy spektrumom meg egy digi-szkopom, egy triggert raallitva szepen ki lehetne merni a gyakorlatban, hogy milyen hosszu is az.
-
A FUSE forráskódja (https://sourceforge.net/p/fuse-emulator/code/HEAD/tree/trunk/libspectrum/timings.c) szerint is 32 T-state 48K-s gépen.
-
A FUSE forráskódja (https://sourceforge.net/p/fuse-emulator/code/HEAD/tree/trunk/libspectrum/timings.c) szerint is 32 T-state 48K-s gépen.
:) Oke en elhiszem, ezek szerint ez a project rossz, pedig azt allitjak, hogy ebbol mukodo ULA-potlokat csinalnak CPLD-ben. Lehet megse ;-P Koszi!
-
úúúúúúú húúúú :)
https://s.zeptobars.ru/Z80A-HD.jpg
-
úúúúúúú húúúú :)
Most kiderült, hogy a Rebelstar térképét honnan lopták.
A memóriabővítős EP alapján a legjobb játéktérképet készíteni, mert abban fel lehet menni egy emeletre is. Ha pedig ügyesek voltunk, csatlakozik jobb oldalon a buszbővítőhöz is minden, ahova tovább lehet menni. Végül a csatlakoztatott winchesterbe is belemászhatunk, a kábeleken mint valami teleporton belesuhanva.
-
az miért van hogy a specyben kevesebb a z80 freki mint az ep-ben?
-
Spectrumon pontos egész arány van a video és a Z80 órajel között, ami egyszerűsíti a hardvert. Egy karakter = 4 Z80 ciklus és 1 Z80 ciklus = 2 pixel. A video órajel választásánál pedig talán az volt a cél, hogy a pixelek közelítően négyzet alakúak legyenek, vagy egyéb okból jobb legyen a kép TV-n. Egy teljes sor 57 karakter Spectrum 128-on (48K-s gépen 56), EP-n és Plus/4-en is. De az is lehet, hogy egyszerűen ennyit tett lehetővé a hardver, például lassú RAM IC-k miatt. :)
-
na és ep-n miért 4mhz? :)
-
na és ep-n miért 4mhz? :)
Mert jobb és gyorsabb. :P De a Specit is szeretjük, az is jó!
-
na és ep-n miért 4mhz? :)
EP-n bármi lehet, mert a video és a Z80 órajel független, 4 MHz a Z80A szabványos frekvenciája. 3.56 MHz lenne a Spectrumhoz hasonló megoldással.
-
EP-n bármi lehet, mert a video és a Z80 órajel független, 4 MHz a Z80A szabványos frekvenciája. 3.56 MHz lenne a Spectrumhoz hasonló megoldással.
aha és akkoriban amúgy volt már gyorsabb z80?
-
aha és akkoriban amúgy volt már gyorsabb z80?
A Wikipédia angol Z80 szócikke az NMOS technológiával gyártott Z80-akat 2,5 (Z80), 4 (Z80A), 6 (Z80B) és 8 (Z80H) MHz-es órajelfrekivel listázza, és ezekre '82 és '83-as hivatkozásokat idéz.
-
Ezen mar elgondolkodtam parszor, nekem tok meglepo volt pl, hogy a 68000-es 1982-ben mar volt 12Mhz-en, de az eredeti 4/6/8MHz-esek mar 1980-ban (bejelentve meg '79-ben). Pedig ez mar ugymond "korszerubbnek" nevezheto, bizonyos szempontbol mar 32 bites (oke, a busz szempontjabol igazabol meg nem ...). Gondolom az ujdonsagok akkor is dragak voltak, es jo idobe kerult, mig valaki kijott egy termekkel ami sikeres lett (ehhez valoszinu az is kellett, hogy ne keruljon egy vagyonba ugye). Nomeg akkor kicsit mas is volt a szamitogep piac mint manapsag az is igaz :)
-
Amennyire én tudom, az Ep kb. 75% -a "fel van készítve" a 6Mhz -en működésre, tehát eleve úgy épült, hogy szinte tudta (volna). Nem tudom, a gép hajdani ára mennyivel lett volna magasabb, ha eleve Z80B -vel szállítják... (Anno mi azzal kezdtük Zozo -val az Ep továbbfejlesztését, hogy kidobtuk belőle a Z80A -t és tettünk e helyére Z80B -t.)
-
azon gondolkodtam, miért nem volt hűtőborda, vagy akár ventillátor a z80-on? nem lehetett volna így nagyobb frekin meghajtani?
-
azon gondolkodtam, miért nem volt hűtőborda, vagy akár ventillátor a z80-on? nem lehetett volna így nagyobb frekin meghajtani?
Ha nagyobb frekin akarták volna meghajtani, akkor sem kellett volna rá! :-) Létezik a Z80/B, (az enyémben is az van) sőt C is, tehát simán mehetett volna pl. 6Mhz -en. :-)
-
Ha nagyobb frekin akarták volna meghajtani, akkor sem kellett volna rá! :-) Létezik a Z80/B, (az enyémben is az van) sőt C is, tehát simán mehetett volna pl. 6Mhz -en. :-)
Ez az egyik. A másik meg, hogy hely az nem sok van hűtőbordák és ventilátorok odaszerelésére, és senki sem lenne boldog egy folyamatosan visító, majd idővel ocsmányul kerregő-daráló, végül örökre elhallgató légkeverővel, és ez utóbbi esemény következményeivel.
-
ezt nem értem. tuti nem mehetett volna nagyobb frekin hiszen akkor annyira állítják...
a hűtőventi hangját meg mindenki utálja, mégis ma a legtöbb pc ilyen :D
a z80 ezek szerint nem melegszik jobban nagyobb frekin? ez elég furcsa :)
-
Én ki is akadtam, amikor az első ventis procit megláttam: "Mi ez a sz...r, már normális procit se tudnak gyártani?"
Z80-ból amúgy 20MHz-es a legnagyobb, mai napig gyártásban van.
-
amúgy, ez a többi ep-s procira is igaz: miért nincs rajtuk legalább hűtőborda, és mennek magasabb frekin :)
amúgy az ep-s bal felső hűtőborda az mit hűt?
lehetett volna úgy is hogy egy kapcsolóval turbó módba kapcsolt ep, ami gyorsabb de saját felelősségre :)
a turbós ep hogy műxik?
-
egy kapcsolóval turbó módba kapcsolt ep, ami gyorsabb
Az költségesebb lett volna, és idő is megcsinálni, és nem sok idejük volt akkor ez EP megjelenésével. A hűtőborda is plusz költség és idő lett volna sajnos.
-
amúgy az ep-s bal felső hűtőborda az mit hűt?
A 7805-ös IC-ket, amik a stabil 5 voltot állítják elő, a többit meg elfűtik.
-
A 7805-ös IC-ket, amik a stabil 5 voltot állítják elő, a többit meg elfűtik.
hm ez érdekes...
ezek szerint ma egy filléres usb táppal kiváltható az egész?
-
ezek szerint ma egy filléres usb táppal kiváltható az egész?
Nem tudom, mennyire stabil az az 5 volt, meg az EP-nek asszem közel 2 amper áramerősség kell, amit a telefontöltők és USB aljzatok szerintem nem tudnak. De többen megcsinálták már, hogy kiváltották a melegedő IC-ket mással, itt, a Hardver részben vannak leírások. Én Kínából rendeltem kapcsolóüzemű feszültségszabályzót, ami Zozo javaslatára biztosítékot is kapott, de voltak jobb megoldások is, amik itthon is beszerezhetők.
-
ezt nem értem. tuti nem mehetett volna nagyobb frekin hiszen akkor annyira állítják...
Gondold végig újra... ;-) (Mást ne mondjak, a belerámolt RAM nem bírta volna követni. Amikor "turbósítottuk" anno az Ep -t, akkor az első volt, amit ki kellett hajítani belőle és gyorsabbakkal pótolni.)
-
Gondold végig újra... ;-) (Mást ne mondjak, a belerámolt RAM nem bírta volna követni. Amikor "turbósítottuk" anno az Ep -t, akkor az első volt, amit ki kellett hajítani belőle és gyorsabbakkal pótolni.)
hát akkor mehet a hűtőborda és a venti a ramokra is :P
-
hát akkor mehet a hűtőborda és a venti a ramokra is :P
Te számítógépes grafikában otthon vagy, és csináltál már modellt is az Entreprise-ról. Nyújtsd meg felfelé 3 centivel, és mesélj, hogy néz ki! Vagy esetleg a billentyűzetet hozd előrébb, és döntsd meg úgy, hogy a hátfaltól számított 15-20 centi hárommal magasabb, mint amilyen most! Gyanítom elég otromba lesz, pedig a gépet részben a dizájnnal akarták eladni.
-
Te számítógépes grafikában otthon vagy, és csináltál már modellt is az Entreprise-ról. Nyújtsd meg felfelé 3 centivel, és mesélj, hogy néz ki! Vagy esetleg a billentyűzetet hozd előrébb, és döntsd meg úgy, hogy a hátfaltól számított 15-20 centi hárommal magasabb, mint amilyen most! Gyanítom elég otromba lesz, pedig a gépet részben a dizájnnal akarták eladni.
mondjuk azt a modellt nem én csináltam.
de értem, viszont okosan meg lehetett volna oldani. az ep felső nagy sík felülete lehett volna egy nagy hűtőborda :)
-
Az új, gyorsabb IC-k se gyorsabbak. Ugyanúgy egy helyben állnak, mint a régiek.
-
érdekeset találtam a wikin: "Fejlett multiprocesszoros üzemmódot támogató lehetőséggel látták el."
ez mi lehet?
-
érdekeset találtam a wikin: "Fejlett multiprocesszoros üzemmódot támogató lehetőséggel látták el."
ez mi lehet?
Gondolom a BUSRQ/BUSAK, azaz, hogy kérésre képes a busz használatát átengedni más eszköznek.
-
Gondolom a BUSRQ/BUSAK, azaz, hogy kérésre képes a busz használatát átengedni más eszköznek.
és ez fejlett? :)
ez, hogy "átengedi" az azt jelenti hogy addig ő nem fér hozzá? mert ez így nem multiproc...