Welcome, Guest. Please login or register.


Author Topic: Z80 (Read 22869 times)

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux Linux
  • Browser:
  • Safari Safari
    • View Profile
    • http://lgb.hu/
Re: Z80
« Reply #15 on: 2011.February.22. 07:56:41 »
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 :)
« Last Edit: 2011.February.22. 08:00:50 by lgb »

Offline Tuby128

  • EP lover
  • *
  • Posts: 955
  • Country: hu
  • OS:
  • Windows Server 2003 Windows Server 2003
  • Browser:
  • Firefox 3.6.13 Firefox 3.6.13
    • View Profile
Re: Z80
« Reply #16 on: 2011.February.22. 08:46:43 »
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 :)
« Last Edit: 2011.February.22. 14:55:03 by tubybb »

Offline Tuby128

  • EP lover
  • *
  • Posts: 955
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.5.3 Firefox 3.5.3
    • View Profile
Re: Z80
« Reply #17 on: 2011.February.22. 15:19:38 »
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)

 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.
« Last Edit: 2011.February.22. 15:24:13 by tubybb »

Offline Attus

  • EP addict
  • *
  • Posts: 1230
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 3.6.13 Firefox 3.6.13
    • View Profile
Re: Z80
« Reply #18 on: 2011.February.22. 16:12:03 »
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:

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux Linux
  • Browser:
  • Safari Safari
    • View Profile
    • http://lgb.hu/
Re: Z80
« Reply #19 on: 2011.February.22. 18:51:41 »
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!

Quote
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).

Quote
- 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 ...

Quote
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)

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.

Quote
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.

Offline Tuby128

  • EP lover
  • *
  • Posts: 955
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.25 Firefox 3.6.25
    • View Profile
Re: Z80
« Reply #20 on: 2012.February.03. 09:30:42 »
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?

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux 64 bit Linux 64 bit
  • Browser:
  • Firefox 5.0 Firefox 5.0
    • View Profile
Re: Z80
« Reply #21 on: 2012.February.03. 10:11:10 »
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. 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.

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux Linux
  • Browser:
  • Safari Safari
    • View Profile
    • http://lgb.hu/
Re: Z80
« Reply #22 on: 2012.February.03. 13:09:24 »
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 :(

Offline Tuby128

  • EP lover
  • *
  • Posts: 955
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.25 Firefox 3.6.25
    • View Profile
Re: Z80
« Reply #23 on: 2012.February.05. 23:49:26 »
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.

Offline Ferro73

  • EP lover
  • *
  • Posts: 765
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 10.0.2 Firefox 10.0.2
    • View Profile
Re: Z80
« Reply #24 on: 2012.March.05. 17:03:05 »
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.

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux Linux
  • Browser:
  • Safari Safari
    • View Profile
    • http://lgb.hu/
Re: Z80
« Reply #25 on: 2012.March.05. 19:48:01 »
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 ...

Offline Ferro73

  • EP lover
  • *
  • Posts: 765
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 10.0.2 Firefox 10.0.2
    • View Profile
Re: Z80
« Reply #26 on: 2012.March.05. 20:28:24 »
Igen a WAIT ha kell pár ciklus órajel

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13519
  • Country: hu
  • OS:
  • Windows 7 Windows 7
  • Browser:
  • Firefox 10.0.2 Firefox 10.0.2
    • View Profile
    • http://enterprise.iko.hu/
Re: Z80
« Reply #27 on: 2012.March.05. 20:31:14 »
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 :-)

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux Linux
  • Browser:
  • Chrome 23.0.1271.52 Chrome 23.0.1271.52
    • View Profile
    • http://lgb.hu/
Re: Z80
« Reply #28 on: 2012.October.29. 09:36:10 »
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), 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 ...

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux Linux
  • Browser:
  • Chrome 30.0.1599.37 Chrome 30.0.1599.37
    • View Profile
    • http://lgb.hu/
Re: Z80
« Reply #29 on: 2013.September.17. 17:09:21 »
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). :)
« Last Edit: 2013.September.17. 17:15:06 by lgb »