De még valószínűbb, hogy az Open Collector-os kimenet a cél.

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

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)

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

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

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.

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!