Welcome, Guest. Please login or register.


Author Topic: CoProcessor (Read 76902 times)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14710
  • Country: hu
    • http://enterprise.iko.hu/
Re: CoProcessor
« Reply #45 on: 2014.September.11. 14:49:24 »
Quote from: Povi
Az U5A és U5B invertereknek mi a célja?
Késleltetés.

Quote
Miért nem lehet közvetlenül összekötni a READY (PAUSE) kimenetet a Z80 WAIT bemenetével?
Gondolom, hogy ne túl korán legyen WAIT :-) Mészárost kéne megkérdezni, vagy majd kipróbálod a gyakorlatban :-)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14710
  • Country: hu
    • http://enterprise.iko.hu/
Re: CoProcessor
« Reply #46 on: 2014.September.11. 14:53:19 »
De még valószínűbb, hogy az Open Collector-os kimenet a cél.

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #47 on: 2014.September.11. 14:53:57 »
Quote from: Zozosoft
Késleltetés.
Gondolom, hogy ne túl korán legyen WAIT :-) Mészárost kéne megkérdezni, vagy majd kipróbálod a gyakorlatban :-)
Ennyit számit az a pár ns? (kb. ilyesmi egy kapu kapcsolása, ugye?) vagy itt még az a felhúzó-ellenálás is beleszól valamit?
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #48 on: 2014.September.11. 15:01:44 »
Ezt irja  a datasheet:
"The PAUSE output of the Am9511 is connected to WAIT line of Z80. The Am9511A outputs a LOW on PAUSE 150ns (max) after RD or WR has become active. The PAUSE remains LOW for 3.5 TCY + 50ns (min) for data read and is LOW for 1.5 TCY + 50ns (min) for status read from Am9511A where TCY is the clock period at which Am9511A is running. Therefore, Z80 will insert one to two extra WAIT states."
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #49 on: 2014.September.11. 20:48:24 »
Most nézem, hogy az Amd, amit rendeltem, 3MHz-es.
Ha nem a 8MHz-ről osztom le az órajelet 2MHz-re (ahogy a kapcsoláson van), hanem külön kristállyal állítom elő neki a 3MHz-es órajelet, akkor működni fog, vagy mindenképpen szükséges, hogy legyen valami szinkron a Z80 órajelével?
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #50 on: 2014.September.12. 11:38:27 »
Még egy kérdés az órajellel kapcsolatban:
A kettővel előző hozzászólásomban lévő képen látszik, hogy az órajelet a Z80 CLK-ról kapja, de inverteren keresztül. Erre miért van szükség?

A másik kérdés a 3MHz-cel kapcsolatban: jól gondolom, hogy működne úgy is, mert a kommunikációt a két chip között a busz szinkronizálja, nem? (bocs, ha hülyén fogalmazok, nem tanultam soha erről, csak hobbi)
« Last Edit: 2014.September.12. 13:02:36 by Povi »
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #51 on: 2014.September.18. 08:58:29 »
Találtam egy jó kis kapcsolást, hogyan lehet a 7490-est órajel-frekvencia osztásra használni.
Az eredeti kapcsolásban egy 7474-gyel van előállitva a 4, vagy 2MHz-es órajel. Az AMD, amit vettem, pedig 3MHz-es.
A 7490-essel a 8MHz-et 3-mal olsztva 2.66MHz-cel meg tudnám hajtani az AMD-t. :-) Igy legalább megspórolok egy külső órajel-áramkört.

I've found a circuit about how to use 7490 as a frequency divider.
The original circuit of the coprocessor-card a 7474 is used to divide the 8MHz to 2 or 4MHz, but my AMD's max freq. is 3MHz. (Why should I use 2MHz, if it could be more? :-))
Using this 7474 as dividing the 8MHz by 3, I'll get 2.66MHz for the AMD, and in this case I can save an external oscillator circuit. :-)
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #52 on: 2014.September.18. 09:19:16 »
Itt van egy érdekes cikk egy 8080-ra irt lebegőpontos rutinról. Ugyanazt a számformátumot használja, amit az Am9511 is használ. Viszont van egy érdekes mondat a cikk végén: "Watch out for "offshore" bargain parts which may be re-marked fake chips." Remélem, hogy az a proci, amit én vettem, nem fake...

Here is an interesting article about early 8080 floating point routines. This uses the same floating point number format as the Am9511. But there is an interesting sentence at the end of the article: "Watch out for "offshore" bargain parts which may be re-marked fake chips." I hope my Am9511 what I bougth in ebay is not fake...
*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: CoProcessor
« Reply #53 on: 2014.September.23. 10:36:27 »
Most ez a pascal-os jatek milyen porton feltetelezi az APU-t? Ahogy az eredeti cikkben volt, 50h-tol? WAIT feature hasznalva van, azaz Z80-at megallitja amig az APU elvan, vagy statusz bitet nezegeted, hogy mikor vegez, es Z80 mehet tovabb? Illetve, van-e barmi tesztprogramod? Arra gondoltam, megprobalom JSep-be APU emulaciot beleheggeszteni ... Csak ehhez szukseg lenne par infora :-)

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #54 on: 2014.September.23. 11:54:14 »
Quote from: lgb
Most ez a pascal-os jatek milyen porton feltetelezi az APU-t? Ahogy az eredeti cikkben volt, 50h-tol? WAIT feature hasznalva van, azaz Z80-at megallitja amig az APU elvan, vagy statusz bitet nezegeted, hogy mikor vegez, es Z80 mehet tovabb? Illetve, van-e barmi tesztprogramod? Arra gondoltam, megprobalom JSep-be APU emulaciot beleheggeszteni ... Csak ehhez szukseg lenne par infora :-)
Minden úgy van (lesz), ahogy az eredeti cikkben. Az 50h-án van az adatport, 51h-n a parancsport, és innét olvassuk ki a status byte-ot is.
A teszt, amit belehegesztettem a Pascal-ba, csak összeszoroz két integer-t, és megnézi, vajon jó lett-e az eredmény:
Code: [Select]
DATAPORT    EQU 050H
CMDPORT     EQU 051H

TestFPU:
; tests FPU
; input: none
; output:
;   A = 1 if FPU is installed
;   A = 0 if FPU is not installed
; destroys C, D, E, H, L
        ld   c,DATAPORT
        ld   de,131
        ld   hl,239
        out  (c),l
        out  (c),h
        out  (c),e
        out  (c),d
        ld   a,06eh         ; SMUL
        out  (CMDPORT),a
        in   h,(c)
        in   l,(c)
        ld   de,31309
        xor  a
        sbc  hl,de
        ret  nz
        inc  a
        ret
illetve ugyanezt a rutint használja a testfpu függvény is (azért van ez trükközés, hogy ha nincs FPU, akkor A=0 legyen, ha van FPU, akkor pedig A=1)

fölrakom az átirt pascal-t is, ebben a lebegőpontos összeadás, osztás és szorzás van kicserélve, emulátoron már nem fut, mert a státuszbájt olvasásakor (ami ugye mindig 0xff lesz), megáll overflow hiábval. Szóval elvileg sima Pascal programmal elvileg tesztelhető a cucc.
*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: CoProcessor
« Reply #55 on: 2014.September.23. 15:12:35 »
Koszi. JSep-ben maris megy :) Igaz meg nem publikaltam (tehat a weboldalon nem ez a verzio van kint!). Foleg azert, mivel szerencsetlen APU emulacio jelenleg egyetlen command-ot ismer, ami az altalad vazolt detektalo rutinhoz kell (SMUL, azt se korrekten szerintem ha elojeles szamok lennenek ...), mast nem :-P Mondjuk az Am9511 adatlap alapjan nem feltetlen egyertelmu par dolog, hogy ezt mikeppen is kene pontosan emulalni ... Probaltam guglizni, de nem igazan van pl Z80 testhez hasonlo program Am9511-hez, amit ra lehetne ereszteni, hogy korrekt-e az emulalas egy valodi APU-hoz kepest. Az altalad mutatott teszt turinbol csinaltam amugy egy exos type-5 programocskat, ami minimalista modon fekete kepernyot produkal ha nincs APU, es pirosat ha van. Vegulis, meghivja a rutinod aztan az A erteket kiirija a 81h portra, kozben interrupts disabled, a vegen meg vegtelen ciklus, oszt' csokolom :)

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #56 on: 2014.September.23. 15:46:16 »
Nem tudom, mennyire akarsz pontos emulálást, legalábbis időzítés szempontjából, mert akkor nem lesz könnyű dolgod, pláne, ha pontosan akarod emulálni pl. a kerekitést, amiről nem nagyon van infóm, no meg valószinűleg "belül" nem 32 bites számokkal dolgozik, hanem többel, persze ez se biztos. :-)
De ha csak az a fontos, hogy az adott parancsra a megfelelő eredményt dobja vissza, az nem tűnik bonyolult dolognak.

Én egyébként azon gondolkodom, ha végre megérkezik a koproci, vajon hogyan tudnám kipróbálni, anélkül, hogy rákötném az EP-re, nehogy hazavágja azt, ha valami fake prociról lenne szó mégis. Gondolkodtam, hogy először mikrokontrollerhez kötném, de annál valami egyszerűbb lenne az igazi.

A Pascal egyelőre csak az FADD, FMUL, FDIV, XCHF, PTOF és SMUL parancsot használja, ha azon akarsz tesztelgetni.
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #57 on: 2014.September.23. 16:13:13 »
Nem tudom, vajon ezt a leírást megtaláltad-e:
http://www.joelowens.org/z80/am9511fpmanual.pdf
itt még folyamatábra is van az FMUL, FDIV és FADD / FSUB parancsokhoz.
*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: CoProcessor
« Reply #58 on: 2014.September.23. 16:15:04 »
Szerintem elso korben az is eleg lesz, ha JavaScript sajat numerikus tipusaval szorakozik, azt meg pop/push belso es kulso muveleteknel konvertalja a ketto kozott, de amugy JS nativ modon maga csinalja. Az biztos, hogy float-nal igy nem lesz tokeletesen pontos (fixednel persze elvarhato ...), bar nem tudom ez mennyire lenne problema. Alapvetoen a JavaScript-nek amugy nincs is kulon egesz es nem egesz tipusa, egy szem numerikus tipus van ami 64 bites. A belso szamabrazolas miatt azonban igen nagy intervallumban (kb vmi 2^53-on, ha jol remlik) egeszkent is pontos marad (annak ellenere, hogy ugye az JS alapvetoen mindig lebegopontosan szamol, az mas kerdes, hogy modern JS engine-ek belsoleg kod analizalas kozben kideritik, hogy adott helyzetben neked integerkent van kvazi hasznalva egy valtozo, de ez a tema messzire vezet, egeszen hajmereszto optimalizalasi lehetosegekig). Vagy vmi hasonlo :) Szoval JS szempontjabol meg mindig pontosabb az APU barmilyen modjanal, az mas kerdes, hogy pont ez okozhat elterest, illetve az APU forumatuma es az JS szamabrazolas kozotti emulator szintu konverzion mulik a dolog.

Viszont pl nekem az sem teljesen vilagos, melyik parancs milyen status flag-et valtoztad meg. Peldak: a NOP nem csinal semmit, es ha elozo muvelet pl a signed flat-et ugy hagyta, a NOP utan is ugy lesz? Vagy minden parancs ujrallitja? Van meg par olyan parancs (ami pl NOS es TOS-t csereli meg) ahol szinten nem vilagos, hogy akkor most a status modosul-e az "uj" TOS (ami elotte a NOS volt) erteke alapjan, hasonlo kerdesem lenne akkor, amikor a TOS-t a NOS-ba masolja (PTOF-nel pl). Na,szoval erted :) Az is erdekes kerdes (vagy csak en nem ertem!), hogy mi tortenik pl egy szorzasnal, ha az eredmeny negativ, es pl fixed-nel csak az also vagy felso fele kell (SMUL, SMUU), akkor mi lesz az elojel a ket esetben? Mondjuk, oszinten szolva annyira nem ragtam at magam a leirason, csak igy "elso ranezesre" tipusu problemaimat vazolom.

EP-s megoldasban van hasznalva a command kod legfelso bitje? Ez ugye elvileg vmi olyanra jo a leiras utan, hogy ezt beallitva az APU tudja jelezni, mikor kesz, vagy vmi hasonlo. Ha ez nem lesz bekotve ugy se, egyszeruen ugy emulalnam az APU-t csak, hogy a command also 7 bitjet nezem csak, a legfelso (SR neven fut) engem nem erdekel.

Az idozites azon is mulik, hogy az APU leallitja-e a Z80-at vagy programban neked kell figyelni a BUSY-t. Ahogy nezem a teszt rutinodat, nem figyelsz szemmit, hogy elkeszult-e az APU, tehat a Z80 addig all, amig az APU dolgozik, jol gondolom? Maga az idozites pedig vagy nincs :) [tehat ultra gyors APU-nk van, hehe, command out utan kesz is azonnal], vagy pedig a specifikacional adott haterertekek szerint veszek egy adott commandra egy atlagot :) Azt nagyon nehez lenne (es szerintem felesleges) megcsinalni, hogy kitalalja az ember, az APU-nal pontosan ciklusra az input adatok tukreben hogy valtozik a vegrehajtasi ido. Szerintem elso korben marad az irreallisan gyors APU megoldas ;) mivel az JSep-ben jelenleg nehezkes az I/O eszkozoknek beleszolni az idozitesbe, csak a CPU opcode-ok tudnak (igen, ez egy hianyossag, es jelenleg pl egy disk sector olvasas a WD fele is nulla orajelciklus alatt kesz). Szerintem azert egy egyszeru programnak az nem "faj" hogy gyors az APU :)

A Pascal altal hasznalt APU parancsokat koszi, ez meg hasznos lehet!

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #59 on: 2014.September.23. 16:25:07 »
Jó kérdések... :-)
A NOP-ról valahol azt olvastam, hogy törli a status byte bitjeit, szóval, legalább erre meg van a válasz.

Én nem nézegetem a status bit 7. bitjét, mert az FPU be lesz kötve a Z80 WAIT lábára. Sőt, a status bájtból csak a hibajelzéshez szükséges 4 bitet nézem (b1..b5), a többivel nem foglalkozom.

Na, itt:
http://www.joelowens.org/z80/am9511algorithms.pdf

azt irja, hogy az XCHF és a PTOF az előjel és zero bitet állitja.

A parancsbyte-ok 7. bitje elvileg azt csinálja, hogy ha lefutott, akkor az SVREQ láb high lesz, ha készen van, de az mivel nem lesz bekötve sehova, szerintem tök mindegy, hogy 0x80-t vagy 0x00-t küldünk pl. NOP-ra.
*** Speicherplatz zu klein