Enterprise Forever

:HUN => Hardver => Topic started by: Tuby128 on 2011.February.21. 05:21:07

Title: CoProcessor
Post by: Tuby128 on 2011.February.21. 05:21:07
Pár helyen már láttam ezt a társprocesszoros témát, és most rászántam egy kis idõt, hogy elolvassam a cikket (http://gafz.enterpriseforever.com/Hardware/Cooprocessor/cooprocessor.htm).
 Így kapcsolási rajz alapján nem tûnik nehéznek elõállítani. Az egyetlen nehézség (inkább drágaság) beszerezni a társprocesszort. Az AM9511 20E Ft, az Intel 8231A 10E körül mozog.

 Arra lennék kíváncsi, hogy a co-proci alkalmazásával milyen programok (vagy játékok) gyorsulnának fel és vajon mennyivel?
Title: Re: CoProcessor
Post by: Povi on 2011.February.22. 14:07:33
nem gyorsulna fel vele semmi...
Title: Re: CoProcessor
Post by: Zozosoft on 2011.February.22. 14:48:25
nem gyorsulna fel vele semmi...
...amíg át nem írja valaki a programokat a használatára.
Title: Re: CoProcessor
Post by: Tuby128 on 2011.February.22. 14:51:18
A 3D-s játékokban a gúla alakú ûrhajókat (Academy) koordináta-transzformációval forgatja 3D-ben a gép, aminél elég sok matematikai számítás szükséges.
A Z80 ráadásul nem tud szorozni, tehát - én úgy érzem - amennyiben exos hívással történik eme dolgok számítása, és sikerül az exost a bõvítõkártyának megfelelõen átírni, akkor talán tapasztalható lehet gyorsulás. Basic-ben tuti biztos.
Title: Re: CoProcessor
Post by: vizor on 2011.February.22. 16:43:22
A régi, 3D-t használó játékokban általában nem használnak eredeti szögfüggvényeket menet közben hanem elõre kiszámítják egy tömbbe, majd felszorozzák 256-al majd csonkítják a tizedest és innentõl máris nem lebegõpontos a dolog de mégis elég "pontos". Mondjuk 1 fokonként a szinuszt majd ugyanezt 90-el eltolva ott a koszinusz. Vagy a progi elején generálja vagy eleve eltárolják fájlba. Szerintem...  :) Régen PC-n így csináltam...
Title: Re: CoProcessor
Post by: Povi on 2011.February.23. 10:13:50
régen sokat vágytam rá, hogy legyen ilyen kártyám
elképzeltem, hogy majd írok rá egy mandelbrot-halmaz rajzoló programot

Zozo, viszont a vinyó-kezelést jelentősen felgyorsítaná, ha át lenne írva a ide.rom, nem?
Title: Re: CoProcessor
Post by: Zozosoft on 2011.February.23. 13:06:35
Zozo, viszont a vinyó-kezelést jelentõsen felgyorsítaná, ha át lenne írva a ide.rom, nem?
Csak a nagyon-nagyon régi vinyók esetén, amik nem tudnak LBA-t. Úgy az utóbbi 15-16 évben gyártottak már mind tudják :-)
Title: Re: CoProcessor
Post by: Tuby128 on 2012.January.22. 14:09:18
Wincseszter kezelésben miért lenne gyorsabb, ha társprocesszor lenne és az IDE.ROM át lenne írva?
Title: Re: CoProcessor
Post by: Zozosoft on 2012.January.22. 19:33:22
Wincseszter kezelésben miért lenne gyorsabb, ha társprocesszor lenne és az IDE.ROM át lenne írva?
Ez a régi nem LBA-s vinyók esetén lenne igaz, ahol a 32 bites szektorszámból csomót kell számoltatni a Z80-t, hogy megkapjuk a C/H/S értékeket. Bár nem túl valószínû, hogy mérhetõ lenne a különbség  :oops:
Title: Re: CoProcessor
Post by: Tuby128 on 2012.January.24. 16:31:10
Miket szoktak implementálni egy CO-processzorba?

Amit sejtek:
(fixpontos és lebegõpontos mûveletek)
összeadás,kivonás, szorzás, osztás
négyzetre emelés, gyökvonás, szögfüggvények


Van még valami?
Title: Re: CoProcessor
Post by: lgb on 2012.January.24. 21:44:58
Miket szoktak implementálni egy CO-processzorba?

Amit sejtek:
(fixpontos és lebegõpontos mûveletek)
összeadás,kivonás, szorzás, osztás
négyzetre emelés, gyökvonás, szögfüggvények

Van még valami?

logaritmus, x az y-odikra emeles, szogfuggvenyek ahogy irtad (altalaban inverz is), meg egy rakas "opcode" amivel az adatok menedzselhetoek (konvertalas, beepitett konstansok neha mint pl a pi, push/pop a stack-jeben, meg hasolok, neha exchange, miegymas).  Ezeket a muveleteket sok esetben lookup tablakbol csinalja (marmint foleg pl szogfuggveny) ami csak kis reszre van tarolva, kihasznalja a fuggveny folytonossagat, es ket pont kozott linearis (esetle komplexebb) kozelitest vegez a pontossag erdekeben stb.

Ezeknek a cuccoknak altalaban egy stack szervezesu 'regiszterkeszlete' van (ha jol remlik igy mux az x86-okhoz tervezett FPU-k is, az mar passz, hogy a 486-os ota a CPU-ra integralt FPU egy mai modern cpu-ban hogy megy: gyanitom ott is megy igy, mert az x86 elonye es atka is egyben ugye a "kotelezo" kompatibilitias.  Ha jol remlik az Am9511 16 es 32 bites fixpontos, es 32 bites float dolgokkal operal (ahogy az EP128 vga-ra topic-ban is irtam: a 9512 jobb, stb de csak 4 alapmuvelet, amug az IEEE formatumu 'szabvany' float kelezese jo am, pl ha C forditot akarsz a gepre, jo ha a float/double abrazolas/szamolas hw-bol megy es compatible pontossag stb teruleten az eloirtakkal).
Title: Re: CoProcessor
Post by: lgb on 2012.January.24. 23:45:03
...amíg át nem írja valaki a programokat a használatára.

Btw, mi van ha pl IS-BASIC-et probalna valaki modositani, hogy sw rutinok helyett adott esetben vmi hw-t hasznaljon? Akkor barmely basic-ben irt cucc azonnal gyorsulhatna ettol, ha sok szamitast hasznal, modositas nelkul. Azt nem tudom, hogy Ep128 eseten szokas-e rom-ban tarolt lebegopontos rutinokat (ami pl a basic interpretere amugy) hasznalni sajat programbol ami mondjuk egy asm project, c64-en kovetnek el neha ilyen csunyasagot :)
Title: Re: CoProcessor
Post by: Povi on 2013.December.09. 21:22:22
8087-es coproci nem jöhetne szóba?
az olcsóbban beszerezhető, kb. 2000-ért e-bay-ről
Title: Re: CoProcessor
Post by: Zozosoft on 2013.December.09. 22:08:48
Quote from: Povi
8087-es coproci nem jöhetne szóba?
Szerintem teljesen kizárt, annyira a 8086-tal van szimbiózisban.
Title: Re: CoProcessor
Post by: Povi on 2014.August.06. 14:51:43
a kinából jövők hamisitványok lehetnek?
http://www.ebay.com/sch/i.html?_odkw=am95&_osacat=0&_from=R40&_trksid=p2045573.m570.l1313.TR0.TRC0.H0.Xam9511&_nkw=am9511&_sacat=0

sokkal olcsóbbak, mint az USA-ból származók
Title: Re: CoProcessor
Post by: Zozosoft on 2014.August.06. 15:57:06
Quote from: Povi
a kinából jövők hamisitványok lehetnek?
Valószínűleg régi panelekből bontott használtak. Ebből azt hiszem nem nagyon volt több féle, így nincs az probléma, mint a Z80-nál, hogy a 4Mhz-esre ráírják, hogy 20Mhz-es.
Title: Re: CoProcessor
Post by: Povi on 2014.September.08. 19:38:40
Vettem egy koprocit 2000 Ft-ért (ingyenes szállítással) az ebay-ről:
http://www.ebay.com/itm/1PCS-AM9511A-AM9511A-1DC-CDIP-ARITHMETIC-PROCESSOR-GOOD-QUALITY-LI2-/360988583027?pt=LH_DefaultDomain_0&hash=item540c98a473
Még van 187 db az eladónak, ha valaki kedvet kapna.

Még nem érkezett meg, legrosszabb esetben csak október közepén jön meg, kíváncsian várom, vajon működik-e.

Tervem az vele, hogy a HiSoft Pascal-t átírjam úgy, hogy a koprocira fordítson. Sajnos nem ugyanaz a lebegőpontos számformátum, de elég hasonló (nem IEEE 754 egyik se).
Title: Re: CoProcessor
Post by: Povi on 2014.September.08. 22:14:29
Gyorsan írtam is egy programot, ami a HiSoft Pascal lebegőpontos formátumát konvertálja át Am9511 formátumra. Egy-két hiányosság van:
a Pascal 23 biten tárolja a mantisszát, az Am9511 pedig 24 biten, tehát az Am9511 formátumban a mantissza LSB-je mindig 0 lesz. Pl. a 0.6 értéke "00 99 99 99" kéne hogy legyen, de így most csak "00 99 99 98" lesz.
Cserébe viszont az Am9511 kitevője csak 7 biten van tárolva a Pascal 8 bitje helyett.
Így a legnagyobb ábrázolható szám az Am9511-en 9,2x1018 (263), míg a Pascalban 3,4x1038 (2x2127).
Title: Re: CoProcessor
Post by: Povi on 2014.September.09. 11:28:47
itt a konvertáló rutin (HiSoft real formátumból Am9511 formátumba), és ki is küldi a procinak az adatot:
Code: [Select]
convert2AMD:
; converts HiSoft Pascal REAL number to Am9511 floating point number
; and sends it to TOS

; input: X (real) in HLDE
;   D     = exponent
;   HLE   = mantissa (b0..b22)
;   H MSB = sign

; output: Am9511 floating number in AHLE and in TOS
;   A     = exponent in b0..b6
;   HLE   = mantissa (b0..b23)
;   A MSB = sign

        ld   a,d        ; D = exponent
        add  a,65
        call m,06a6h    ; if exp > 62 or exp < -65 then overflow error
        xor  a
        sla  e
        rl   l
        rl   h          ; rotates left HLE
        rra             ; MSB of A = sign
        inc  d
        res  7,d
        add  a,d
        ld   c,DATAPORT
        out  (c),e
        out  (c),l
        out  (c),h
        out  (c),a
        ret
A kérdésem az volna, hogy jó-e igy a 4 byte küldése? Fogja tudni fogadni az AMD az adatot? Sajnos a buszrendszerek működésével nem vagyok igazán tisztában.
Title: Re: CoProcessor
Post by: lgb on 2014.September.09. 13:56:55
Quote from: Povi
itt a konvertáló rutin (HiSoft real formátumból Am9511 formátumba), és ki is küldi a procinak az adatot:

Az gondolom joval nehezebb lenne, hogy ne kelljen konvertalgatni, hanem az Am9511 formatuma legyen a "nativ". Es max a sw-es rutinokat ujrairni az coproc formatumra, hogy azert a hw hianyaban is menjen. Mivel konkretan semennyire nem ismerem a HiSoft pascal-t, konnyen jartatom a szamat :-P
Title: Re: CoProcessor
Post by: Povi on 2014.September.09. 14:28:02
Ez lenne  a jobb megoldás, de ahhoz mélyebben bele kéne nyúli a Pascal lelkivilágába, erre (sajnos) nem vagyok képes. :-)
Jelenleg úgy működik a Pascal, hogy egy operandusos függvényeknél (pl. SIN) a HLDE-ben van az input, meghija az adott rutint, és HLDE-ben adja vissza az eredményt. Két operandus esetén (pl. osztás) az első op. (az osztandó) a veremben van, a második (az osztó) a HLDE-ben, meghivja a rutint, és HLDE-ben megkapjuk az eredményt.

A tervem:
egy op. esetén (pl. SQRT):
  1. HLDE átalakitva Am9511 formára, és kiküldi a procnak.
  2. Kiküldi a megfelelő parancsot.
  3. Visszaolvassuk az eredményt, és ezt visszakonvertálom Pascal REAL-ra, a HLDE-be.

Két op. esetén (osztás):
  1. HLDE átalakitva Am9511 formára, és kiküldi a procnak.
  2. Veremből kivesszük  a 2. operandust.
  3. Átalakitom ezt is Am9511 formára, és kiküldeni a procnak.
  4. osztás esetén TOS és NOS csere parancs küldése a procnak (hogy ne az osztót ossza az osztandóval). Összeadásnál és szorzásnál nincs szükség erre a cserére.
  5. Kiküldi a megfelelő parancsot. (osztás)
  6. Visszaolvassuk az eredményt, és ezt visszakonvertálom Pascal REAL-ra, a HLDE-be.

Annyira talán nem sok idő a konvertálás... :-)
Title: Re: CoProcessor
Post by: Povi on 2014.September.09. 14:43:45
Itt  az eredmény beolvasása a koprociból, és a számformátum átalakítása Pascal formába:
Code: [Select]
GetResult:
; get result from TOS and converts to HiSoft Pascal REAL format
        ld   c,DATAPORT
        in   d,(c)
        in   h,(c)
        in   l,(c)
        in   e,(c)       
        ld   a,80h
        and  d          ; MSB of A = sign, clear Carry
        res  7,d        ; clear sign in D
        dec  d
        bit  6,d
        jr   z,notset
        set  7,d
notset: rr   h
        rr   l
        rr   e          ; rotates right HLE
        add  a,h
        ld   h,a
        ret
Nem tudom, van-e valami elegánsabb megoldás arra, hogy csak akkor állítsa be a D regiszter 7. bitjét, ha a 6. be van állítva.
Title: Re: CoProcessor
Post by: IstvanV on 2014.September.09. 15:07:00
Ha nem fontos, hogy A = H legyen:
Code: ZiLOG Z80 Assembler
  1.         ld      c, DATAPORT
  2.         in      a, (c)
  3.         ...
  4.         in      e, (c)
  5.         add     a, a
  6.         rr      h
  7.         rr      l
  8.         rr      e
  9.         sub     2
  10.         sra     a
  11.         ld      d, a
  12.         ret

Az IN A, (C) helyett lehet IN A, (DATAPORT) is, ami még 1 ciklussal gyorsabb. :)
Title: Re: CoProcessor
Post by: Povi on 2014.September.09. 15:29:30
Ez zseniális, köszönöm!!!
Teli van a kód apró ötletekkel, nem tudom, milyen agy kell ehhez, de igazából pont az ilyen kódolások miatt szerettem meg az assembly-t. :-)
Title: Re: CoProcessor
Post by: Ferro73 on 2014.September.09. 16:41:38
Esetleg ha memcim-et használnál és OUTI, INI  utasítást használnál?
PL:
   ld   hl,kezd cdhle
   ld   bc,xxx   ; b=4 C= DATAPORT
   outi

   ld   hl,kezd cdhle
   ld   bc,xxx   ; b=4 C= DATAPORT
   ini
Title: Re: CoProcessor
Post by: Povi on 2014.September.09. 19:12:40
Gondolkodtam én is rajta, de 4 byte miatt nem éri meg, nem lesz se gyorsabb, se rövidebb a kód.
A 4 byte kiküldése a portra OUT (C),reg utasítással 4x12T, plusz 7T a C-nek kezdőértéket adni (összesen 55T).
4 byte kiírása a memóriába LD (HL),reg utasítással 4x7T, HL kezdőérték adás 10T (eddig 38T), de a HL értékét 3x növelni kell, ez minimum 3x3T (ha INC L-t használunk csak), és még mindig csak a memóriában van a 4 byte-om, ahonnét OUTI-val ki kéne küldeni.
Title: Re: CoProcessor
Post by: Povi on 2014.September.09. 19:28:49
Itt van egy rövidke program, ami kiírja a Pascal lebegőpontos formátumot, átszámolja Am9511 formátumra, majd vissza alakítja Pascal formátumra.
http://ep.lgb.hu/jsep/demo/?snapshot=http%3A%2F%2Fbeac.uw.hu%2Fbigyo.ep128s&autostart=yes
A visszaalakító kód István műve.
Nulla esetén még nem biztos, hogy jó a konvertálás, a Pascal 00 00 00 00-t ad HLDE-nek, de igazából csak a H 6. bitjét nézi, hogy az nulla-e. Nem egyértelmű az Am9511 doksijából, vajon elég-e, ha a mantissza MSB-je nulla, vagy mind a 32 bitnek 0-nak kell lenni.
Title: Re: CoProcessor
Post by: BruceTanner on 2014.September.09. 21:37:39
(via google translate) You can improve the first routine too. 
Code: [Select]
        ld      a,d
        cp      -65
        call    m,06a6h
        inc     a
        add     a,a     ; lose MSB, will shift back later with sign
        sla     e
        adc     hl,hl   ; same as rl l, rl h but quicker
        rra             ; shift back with sign
        ld      c,DATAPORT
            :
            :
Title: Re: CoProcessor
Post by: Povi on 2014.September.09. 21:43:28
Thanks a lot your help!
Title: Re: CoProcessor
Post by: lgb on 2014.September.09. 21:58:50
Quote from: BruceTanner
(via google translate) You can improve the first routine too.

I'm curious if IS-BASIC can be modified somehow to use hardware coprocessor instead of software routines. But since IS-BASIC uses some kind of BCD logic (at least what I remember from my project to convert exos type-4 files into text or HTML on PC), I am not sure how easy/hard and efficient to do this ...
Title: Re: CoProcessor
Post by: gflorez on 2014.September.09. 23:39:45
It seems that some coprocessors manage BCD natively:

http://en.wikipedia.org/wiki/Intel_8087
Title: Re: CoProcessor
Post by: lgb on 2014.September.10. 00:16:15
Quote from: gflorez
It seems that some coprocessors manage BCD natively:

http://en.wikipedia.org/wiki/Intel_8087

Maybe, but Am9511 is known at least to expand the Enterprise, I don't know about other existing solutions (hey, is there a real Am9511 for EP, or is it only a newspaper arcticle I've also read?). I guess FPUs for intel x86 family are too deeply bound to the x86 CPUs and can't be easily used with other CPUs like Z80 (but I can be wrong). I am also curious if there is some more modern solution for having an FPU other than the Am9511. uM-FPU is not so bad, but it's SPI based stuff.
Title: Re: CoProcessor
Post by: gflorez on 2014.September.10. 00:51:57
You are right, seems that a 8087  only acts as an extension of the 8086 or 8088 assembler set .
Title: Re: CoProcessor
Post by: Povi on 2014.September.10. 07:11:35
Quote from: lgb
I'm curious if IS-BASIC can be modified somehow to use hardware coprocessor instead of software routines. But since IS-BASIC uses some kind of BCD logic (at least what I remember from my project to convert exos type-4 files into text or HTML on PC), I am not sure how easy/hard and efficient to do this ...
Yes, it would be an interesting project. I don't know anything about IS-BASIC number format, is it some kind of fixed point number?
Title: Re: CoProcessor
Post by: Povi on 2014.September.10. 07:20:02
Quote from: lgb
Maybe, but Am9511 is known at least to expand the Enterprise, I don't know about other existing solutions (hey, is there a real Am9511 for EP, or is it only a newspaper arcticle I've also read?). I guess FPUs for intel x86 family are too deeply bound to the x86 CPUs and can't be easily used with other CPUs like Z80 (but I can be wrong). I am also curious if there is some more modern solution for having an FPU other than the Am9511. uM-FPU is not so bad, but it's SPI based stuff.
I've find a small  article about comparison of Amd and uM FPU-s, and it seems, on the same frequency the uM has similar speed as Amd.
http://www.cpushack.com/2010/09/23/arithmetic-processors-then-and-now/
OK, big advance of uM, it has IEEE 754 format (like the Am9512).
On the datasheet of Am9511 there is a speed comparison to software routines. A BASIC has the some floating point number format, like the Am9511, so it can be compare, and in average, the FPU is 50 times faster than software routines.

Találtam egy rövidke cikket, ami összehasonlítja (vagy inkább csak megemlíti) az AMD és a uM koprocit, és ez alapján úgy tűnik, azonos órajelen nagyjából azonos sebességűek.
http://www.cpushack.com/2010/09/23/arithmetic-processors-then-and-now/
OK, tudom, nagy előnye a uM-nak, hogy tudja az IEEE 754 formátumot, míg az Am9511 nem (csak az Am9512).
Az Am9511 adatlapján van egy teszt, ahol összehasonlítják a sebességét szoftveres rutinokkal (nagy szerencsére az egyik BASIC pont ugyanazt a lebegőpontos számformátumot használja, mint az AMD), és átlagban 50x gyorsabb a koproci. (2 perc helyett 2,5 mp alatt megrajzol egy Mandelbrot ábrát! :-))
Title: Re: CoProcessor
Post by: lgb on 2014.September.10. 09:16:17
Quote from: Povi
Yes, it would be an interesting project. I don't know anything about IS-BASIC number format, is it some kind of fixed point number?

It's an interesting stuff, it's - if I remember correctly - packed BCD format (on hmmm maybe 5 bytes, so 10 digits) with an exponent byte. But I guess Bruce knows it much-much-much better :) http://ep128.hu/Ep_Konyv/Gepi_kod_2.htm#342 (http://ep128.hu/Ep_Konyv/Gepi_kod_2.htm#342)
Title: Re: CoProcessor
Post by: Povi on 2014.September.10. 10:10:01
A Pascal RTL rutinjait valahogy így kéne lecserélni:
Code: [Select]
;--------------------------
; X / Y Real
; input:
;   X in stack
;   Y in HLDE
; output:
;   X / Y in HLDE
;--------------------------
l0acd:  call convert2AMD        ; convert Y to AMD format and send it to AMD
        pop  bc                 ; get return address from top of the stack
        pop  de
        pop  hl                 ; HLDE = X
        push bc                 ; push return address
        call convert2AMD        ; convert X to AMD format and send it to AMD
        ld   a,019h             ; code for XCHF (exchange 32 bit operands)
        out  (CMDPORT),a
        ld   a,013h             ; code for FDIV
        out  (CMDPORT),a
        call error_handling
        jp   GetResult
Igen, tudom, hogy a rutinok igy csak a CMDPORT-ra kiküldött bájtban különböznek, az első hat sor minden kétoperandusos rutin elején azonos lenne, de mivel annyi hely van (jóval hosszabbak a szoftveres lebegőpontos rutinok), hogy a gyorsaság miatt maradhat igy (egy CALL / RET -tel kevesebb). XCHF is csak az osztásnál kell.
Title: Re: CoProcessor
Post by: Povi on 2014.September.10. 10:14:43
a hibakezelő rutin pedig ez lenne:
Code: [Select]
error_handling:
        in   a,(CMDPORT)
        and  00011110b
        ret  z                  ; return if no error

        cp   00010000b
        jp   z,06b5h            ; Divide by zero

        cp   00001000b
        jp   z,06c4h            ; Maths call error

        cp   00011000b
        jp   z,06a1h            ; Number too large

        and  00000010b
        jp   nz,06a6h           ; Overflow

        ld   de,underflow_msg
        jp   0103h

underflow_msg:
        db   "Underflow",0

Az Underflow és Overflow hibánál a 3. és 4. bit állapota ismeretlen, ezért van AND a CP helyett.
Title: Re: CoProcessor
Post by: gflorez on 2014.September.10. 10:33:24
Some other things than BASIC work too on BCD, for example the internal clock.
Title: Re: CoProcessor
Post by: IstvanV on 2014.September.10. 12:16:57
Quote from: lgb
It's an interesting stuff, it's - if I remember correctly - packed BCD format (on hmmm maybe 5 bytes, so 10 digits) with an exponent byte. But I guess Bruce knows it much-much-much better :) http://ep128.hu/Ep_Konyv/Gepi_kod_2.htm#342 (http://ep128.hu/Ep_Konyv/Gepi_kod_2.htm#342)
If I recall correctly, it is 14 digits (7 bytes) BCD with an additional byte for the sign and exponent. Even without a co-processor, it could be possible to make it faster with IEEE-style 32-bit binary floats that are good enough for many of the BASIC programs, but the BCD format would ideally need to be replaced everywhere in the ROM.
Title: Re: CoProcessor
Post by: Povi on 2014.September.10. 16:08:35
Azon gondolkodok, vajon az SADD (16 bites előjeles egész összeadás) utasítás vajon miért került bele a koprociba? Az adatlap szerint 16-18 órajel ciklus alatt fut le, miközben egy sima ADD HL,DE pedig csak 11 ciklus. És akkor még nem számoltam az adatok és a parancs kiküldésének az idejét...
Title: Re: CoProcessor
Post by: Zozosoft on 2014.September.10. 16:13:51
Nem lehet, hogy olyan proci mellé szánták ami nem ismert ilyet?
Az adatokat mindig újra kell küldeni? Nem lehet előző számítás eredményével újabb műveletet végezni?
Title: Re: CoProcessor
Post by: Povi on 2014.September.10. 16:41:16
Quote from: Zozosoft
Nem lehet, hogy olyan proci mellé szánták ami nem ismert ilyet?
Az adatokat mindig újra kell küldeni? Nem lehet előző számítás eredményével újabb műveletet végezni?
Nem tudom, milyen más proci lehetett a 70-es évek legvégén, ami nem tud összeadást... :-) (persze lehet, hogy én vagyok tudatlan).
De, lehet, az eredmény a verem tetején lesz. Aztán beküldök még egy operandust, aztán egy szorzást, és csak utána olvasom ki az eredményt. Azt is lehet, hogy előre betöltök a verembe 8 db integer-t, majd kiadok egymás után 7 darab összeadást, és utána olvasom csak ki az végeredményt. Igazából RPN módszerrel működik, ahogy nézem.
Title: Re: CoProcessor
Post by: Povi on 2014.September.10. 18:21:22
Quote from: Povi
a hibakezelő rutin pedig ez lenne:

végül is rra-kkal is meg lehetne oldani, ha nem fontos, hogy a "Number too large" és a "Maths call error" meg legyen különböztetve... Rövidebb is, gyorsabb is.
Title: Re: CoProcessor
Post by: Povi on 2014.September.11. 14:41:41
http://ep128.hu/Ep_Hardware/Pic/Rajz_Koopproci.gif
Az U5A és U5B invertereknek mi a célja?
Miért nem lehet közvetlenül összekötni a READY (PAUSE) kimenetet a Z80 WAIT bemenetével?
Title: Re: CoProcessor
Post by: Zozosoft 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 :-)
Title: Re: CoProcessor
Post by: Zozosoft on 2014.September.11. 14:53:19
De még valószínűbb, hogy az Open Collector-os kimenet a cél.
Title: Re: CoProcessor
Post by: Povi 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?
Title: Re: CoProcessor
Post by: Povi 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."
Title: Re: CoProcessor
Post by: Povi 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?
Title: Re: CoProcessor
Post by: Povi 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)
Title: Re: CoProcessor
Post by: Povi 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 circui (http://ep128.hu/Ep_Hardware/Pic/Rajz_Koopproci.gif)t 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. :-)
Title: Re: CoProcessor
Post by: Povi on 2014.September.18. 09:19:16
Itt (http://www.retrotechnology.com/herbs_stuff/float.html) 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 (http://www.retrotechnology.com/herbs_stuff/float.html) 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...
Title: Re: CoProcessor
Post by: lgb 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 :-)
Title: Re: CoProcessor
Post by: Povi 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.
Title: Re: CoProcessor
Post by: lgb 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 :)
Title: Re: CoProcessor
Post by: Povi 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.
Title: Re: CoProcessor
Post by: Povi 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.
Title: Re: CoProcessor
Post by: lgb 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!
Title: Re: CoProcessor
Post by: Povi 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.
Title: Re: CoProcessor
Post by: lgb on 2014.September.23. 17:21:57
Koszi, el is felejtettem nagy emulator irasi lelkesedesemben, hogy kereshetnek mas, reszletesebb leirast is :) Meglatjuk, mi sikerul. Azert tenyleg jo lenne egy mukodi "igazi" APU-hoz hasonlitani, ahhoz viszont tenyleg kene egy EP APU-val ... (vagy mas, de APU-val ...). Z80 opcode emulacio egyszerubb, van rakas mas emulator is, van rakas gep, amiben Z80 van, de az Am9511 azert nem feltetlen olyan elterjedt ma mar, hogy lehessen az igazi "vashoz" viszonyitani, illetve pl olyan emulatort/projectet sem talaltam, ahol Am9511-et emulalnak esetleg. Nem baj, igy nagyobb a kihivas :D

Amugy az is eszembe jutott, hogy ha mar van egy gep (EP), ahol buszke lehet az ember, hogy hasonlo gepekhez kepest OS is van (EXOS), akkor bele kene pakolni az APU detektalast is, es pl lekerdezhetove tenni (EXOS valtozo?). Vagy akar egy kis ROM, vagy mas ROM-ba bele (ZT, akarmi), esetleg olyan rutinokkal, amit meg is lehet hivni, es APU jelenlete eseten megcsinaltatja azzal, kulonben meg software-esen emulalja. Bar, lehet, elszaladt velem lo, hiszen nem lehet arra epiteni, hogy mindenkinek lesz ilyenje, mar annak is orulni kell, ha alap EP-je van az embernek igazabol is ...
Title: Re: CoProcessor
Post by: Povi on 2014.September.23. 17:33:40
Quote from: lgb
Amugy az is eszembe jutott, hogy ha mar van egy gep (EP), ahol buszke lehet az ember, hogy hasonlo gepekhez kepest OS is van (EXOS), akkor bele kene pakolni az APU detektalast is, es pl lekerdezhetove tenni (EXOS valtozo?). Vagy akar egy kis ROM, vagy mas ROM-ba bele (ZT, akarmi), esetleg olyan rutinokkal, amit meg is lehet hivni, es APU jelenlete eseten megcsinaltatja azzal, kulonben meg software-esen emulalja. Bar, lehet, elszaladt velem lo, hiszen nem lehet arra epiteni, hogy mindenkinek lesz ilyenje, mar annak is orulni kell, ha alap EP-je van az embernek igazabol is ...
Erre én is gondoltam már, de egyelőre működjön az igazi "vas", aztán lehet fejleszteni... :-)
Igazából az IS-BASIC-be lehetne még belerakni, és mivel ez interpreter, a meglévő BASIC programok egyből gyorsabban futnának, ha van FPU. A Pascal esetében meg ugye újra kell fordítani a forráskódot, hogy az FPU rutinokat használhassuk.
Title: Re: CoProcessor
Post by: lgb on 2014.September.23. 21:51:12
http://ep.lgb.hu/jsep/demo.new/ (http://ep.lgb.hu/jsep/demo.new/)

Vigyazat, csak a demo.new-s jo, a sima demo-sban nincs APU kezdemeny se! Na ez a legelemibb, csak a fentebb beszelt Am9511 detektalo rutinra jo stuff, mas cmd-t nem nagyon ismer :) A default disk image-en rajta van a hp13.com is most, minden extra URL param nelkul igy betoltheto. A pascal ki is irja hogy Am9511 detected. Az emulator stop gombbal valo leallitasa utan a "debug ablakban" lehet is nezelodni, az APU: kezdetu sorokra erdemes figyelni nyilvan. Most majd inkabb aztan azokkal a commandokkal szorakozok, amit emlitettel, hogy HP APU-s "verzioja" jelenleg hasznalja.
Title: Re: CoProcessor
Post by: Povi on 2014.September.23. 22:24:58
ezzel lehet esetleg tesztelni, hogy működik-e:

a fordítás előtt a compiler stack-et és a translate stack-et BF00H-ra kell állítani!!!

("A" parancs -> Alter)
Title: Re: CoProcessor
Post by: lgb on 2014.September.24. 14:58:53
Van egy erzesem, hogy vmit elrontok en az Am9511 format konvertalasnal. Mivel te foglalkoztal mar vele a pascal kapcsan, megtenned azt a szivesseget, hogy elkuldod azt a 32 bitet, ami pl a kovetkezo ertekek Am9511 float formatumra konvertalas utan adodik? Pelda: legyen mondjuk a PI a formatum altal lehetove tett max pontosaggal,    0.5    16    256    0.25    100.5    (tizedes pontkent ertendo a pont ...).

Ami amugy konkretan gyanus: elvileg a 2-es alapu binaris szamabrazolas pont annak kedvez, ha a ketto hatvanyarol van szo, megis, nekem akkor jonnek ki nem teljesen kerek ertekek (pl a 16 mint szam Am9511-re konvertalasa majd vissza ezt adja: 15.999999046325684. Ez ugye nem meglepo nehany esetben, amde pont a ketto egy hatvanyanal nekem fura (bar belekeveredtem mar abba is, hogy itt a mantissa maskepp van normalva mint pl a "szokasos" IEEE 32 bites float formatumnal es a mantissa MSB-je mindig 1 _kell_ hogy legyen kiveve a nullat, de akkor minden bit nulla az egesz 32 bites alakban amugy is).

Koszi szepen, ha ezzel tudsz segiteni :)
Title: Re: CoProcessor
Post by: Povi on 2014.September.24. 15:07:29
0.5 = 0x00 0x80 0x00 0x00
16 = 0x05 0x80 0x00 0x00
256 = 0x09 0x80 0x00 0x00
0.25 = 0x7f 0x80 0x00 0x00
100.5 = 0x07 0xc9 0x00 0x00

(http://www.joelowens.org/z80/fp10.jpg)

(http://www.joelowens.org/z80/fp32.jpg)
Title: Re: CoProcessor
Post by: lgb on 2014.September.24. 15:15:05
Koszi. Amugy nekem is van ra formulam, leirasom stb, csak vmiert nem akar osszejonni :) Erdekes modon a 100.5 az korrekt, pontosan igy nez ki nalam is, ahogy leirtad. Viszont ha egy szam a ketto hatvanya (lehet negativ hatvanya is, pl 0.5 vagy 0.25) az elegge masra jon ki. Szerintem vmi normalizalasi gond lesz ez itt nekem.
Title: Re: CoProcessor
Post by: Povi on 2014.September.24. 15:25:44
Most már viszont kiváncsi vagyok, neked mi jött ki pl. 0.5-re és 16-ra :-)
Furcsa, hogy 100.5-re ugyanaz, kettő hatványainál meg tök más.
Title: Re: CoProcessor
Post by: lgb on 2014.September.24. 15:39:14
Quote from: Povi
Most már viszont kiváncsi vagyok, neked mi jött ki pl. 0.5-re és 16-ra :-)
Furcsa, hogy 100.5-re ugyanaz, kettő hatványainál meg tök más.

Szerintem az en hibam volt. JS numeric -> Am9511 float format konverzios algoritmusom egy remalom, de kb ezt csinalom (a szam elojelet most kiagyom, valojaban az abszoluterteket nezem, es az eredeti szam elojele alapjan a vegen allitom be):

Code: [Select]
exp = Math.ceil(Math.log2(data)); // meghatarozzuk a 2 hatvanyat
data = data / Math.pow(2, exp); // eredti szamot elosztjuk a megfelelo ketto hatvanyaval (exp-ben van, a Math.pow az a hatvanyozas) igy talan kijon az, amibol majd a mantissa lesz
data = (data * 16777216.0) | 0; // a mantissat skalazzuk 24 bitre, a | 0 egyreszt JS optimalizacio (logikai "vagy"), masreszt integer szeru hatast okoz JS-ben, ezt gyakran hasznaljak

Bar van benne nemi JS furcsasag (pl a | 0) szerintem ertheto. Az elejen a data-ban van a szam, ebbol lesz az exp, es a data (ami a mantissa lesz). Itt volt egy problema: a ketto hatvanyainal pont az jott ki, hogy a mantissa erteke nem fert el 24 biten. Ezert, ha a vegen a data nem fer bele a 24 bitbe, akkor shiftelem egyet jobbra (magyaran osztom kettovel) es persze az exp-et novelem egyel. Igy most jonak tunik a ketto hatvanyaira _es_ barmi mas szamra is amivel hirtelen probaltam. Persze az aktualis rutin joval nagyobb ennel, mert ugye az exp felso bitjebe kell elojel, kezelni kell, ha az JS numeric eredmeny nem fer bele az Am9511 abrazolhato tartomanyba, az emlitett negativ szam kerdese, illetve nulla eset meg a fenti rutin elott kezelendo, mert a Math.log2 (2-es alapu logaritmus) nem fog orulni a nullanak :)

Igazabol nem tudom, hogy van-e normalisabb algoritmus erre, amit nekem sikerult itt osszeganyolni teljesen sajat otletek alapjan :)

A problemat az en hulyesegem okozta: tettem bele egy olyan ellenorzest, hogyha a data a vegen (mantissa) nem fer bele a neki kello helybe, akkor 24 bitnyi 1-essel helyettesitettem. Ezaltal allt elo az a vicces szitu, hogy pl a 16-ot Am9511-esitve, majd vissza, a 16-ot alulrol kozelito szamot kaptam es nem pontosan 16-ot :) Ezt az idiota kodreszletet csereltem ki a "shift jobbra a mantissa-ra, exp novelese egyel" megoldassal.

Azert, ha van hozzafuzni valod, hogy ezt hogy lehetne egyszerubben megoldani, ne tartsd vissza kerlek :)

Mas: most hany MHz-en fog menni az APU vegulis? :)
Title: Re: CoProcessor
Post by: Povi on 2014.September.24. 16:27:28
Amit vettem, az 3MHz-es, de egyelőre 2MHz-en fog menni, az eredeti kapcsolás szerinti frekiosztó lesz bekötve. Ha működik, majd veszek egy 7490-est, aztán mehet 2.66-tal, vagy megoldom külső órajellel, és akkor 3Mhz. De létezik az IC-nek 4MHz-es változata is, az a maximum.
Title: Re: CoProcessor
Post by: Povi on 2014.September.24. 16:31:41
Quote from: lgb
Azert, ha van hozzafuzni valod, hogy ezt hogy lehetne egyszerubben megoldani, ne tartsd vissza kerlek :)


Én biztos úgy oldottam volna meg - bár nem tudom, JavaScript-ben mennyire lehet hozzáférni a natív 64 bites lebegőpontos formátumhoz - hogy azt konvertálnám át bittologatással, végül is ott már meg van a szám kettes alapon.
Title: Re: CoProcessor
Post by: lgb on 2014.September.24. 16:37:43
Quote from: Povi
Én biztos úgy oldottam volna meg - bár nem tudom, JavaScript-ben mennyire lehet hozzáférni a natív 64 bites lebegőpontos formátumhoz - hogy azt konvertálnám át bittologatással, végül is ott már meg van a szám kettes alapon.

Na igen, de ez a "baj" az JS-el ami az elonye is: platformfuggetlen. Azaz sima szamkent hasznalva nincs gond, de ha a szam belso felepitesehez fersz hozza (normal esetben nem lehet, de pl typedarray-n at igen, igaz akkor csak 32 bites float-hoz, ami ha mas mantissa/exp bit aranyt hasznal akar precizitas csokkenest is okozhatna az eredeti Am9511-hez kepest, vagy nem is olyan tag a szamtartomany es nem menne! Az JS nativ numeric formatuma nem gond, az 64 bites lebegopontos, boven eleg, viszont ahhoz nem tudsz bit szinten hozzaferni), akkor az mar akar hardware fuggo is lehet (big es little endian, de lehetnek akar mas elteresek is). Az ilyen platformfuggetlen cuccokat pont azert talaltak ki, hogy elfedje a gepi reprezentaciot, ami a web szempontjabol elony nyilvan, most viszont hatrany. Oszinten szolva, en is gondolkodtam rajta, hogy par ertekkel az emu teszteli az elejen hogy pl hova kerul a mantissa stb, es az alapjan dolgozik vele, de felek tole, hogy nem ilyen egyszeru es akar mas elteresek is lehetnek, hogy pl nem is ugyanannyi bit jut mantissa/exp-re, mashol tarolja az elojelet stb. Ha ezt mind le akarod kezelni, olyan programod lesz JS-ben, aminel lenyegesen egyszerubb az en matematikai eljarasom. Viszont, most elgondolkodtam, guglizok majd, hogy mennyire std az JS szamabrazolasa, es ha csak a byte order (big/little endian) kulonbozik, az meg siman kezelheto.
Title: Re: CoProcessor
Post by: Povi on 2014.September.24. 16:38:49
Sőt, ha jól nézem, akkor lenne a legegyszerűbb a konvertálás, ha 32 bites lenne a JavaScript-es ábrázolás. Ott 23 biten van a mantissza, azt egy az egyben át lehetne venni, az Am9511 alsó 23 bitjére, a mantissza MSB-jét 1-re állítjuk, majd a kitevőt növeljük eggyel. (persze még játszani kell egy kicsit, mert vizsgálni kell, vajon belefér-e a kitevő 7 bitbe)
Title: Re: CoProcessor
Post by: Povi on 2014.September.24. 16:43:22
Quote from: lgb
Na igen, de ez a "baj" az JS-el ami az elonye is: platformfuggetlen. Azaz sima szamkent hasznalva nincs gond, de ha a szam belso felepitesehez fersz hozza (normal esetben nem lehet, de pl typedarray-n at igen, igaz akkor csak 32 bites float-hoz, ami ha mas mantissa/exp bit aranyt hasznal akar precizitas csokkenest is okozhatna az eredeti Am9511-hez kepest, ulonbozik, az meg siman kezelheto.
Na, akkor talán mégis csak ez a megoldás! :-)

Az IEE754 23 biten ábrázolj a mantisszát, de mégis 24 bites a pontossága, mert úgy veszi, hogy a 24. bit az mindig 1. :-) Vagyis 1.011110110... stb. formában. Az AM9511 pedig csak 23 bit pontosságú, szóval nem veszítenék pontosságot (itt ugye 0.111001000 stb, ahol a 2-1 helyiértéken lévő bit mindig = 1.
Title: Re: CoProcessor
Post by: lgb on 2014.September.24. 16:44:37
Quote from: Povi
Sőt, ha jól nézem, akkor lenne a legegyszerűbb a konvertálás, ha 32 bites lenne a JavaScript-es ábrázolás. Ott 23 biten van a mantissza, azt egy az egyben át lehetne venni, az Am9511 alsó 23 bitjére, a mantissza MSB-jét 1-re állítjuk, majd a kitevőt növeljük eggyel. (persze még játszani kell egy kicsit, mert vizsgálni kell, vajon belefér-e a kitevő 7 bitbe)

JS numeric tipusa 64 bites, de ahhoz nem lehet hozzaferni belsoleg. Ahogy irtam, TypedArray Float32 van, az 32 bites, es hozza is tudsz ferni byte-onkent is. Ezzel az a gond, hogy ez platformfuggo (a szamabrazolas), a standard azt irja, hogy a Float32 az adott hw-n nativ szamabrazolas, eleve a big/little endian biztos jatszik, de sajnos mas elteresek is lehetnek :(

A bit szinten valo machinalassal valo konverzio valoban jobb lenne, es pl a pascal-ban valo alkotasod soran realis is: elvegre adott az Am9511 formatuma, es a pascal altal Ep-n hasznalt szinten formatum. Az en esetemben mar gond van, mert az egyik oldalon az JS van, ami mas-mas hw-n futva akar mas is lehet (az endian kerdes amugy a legnepszerubb problema: pl okostelefonok stb eseten - mondjuk ARM CPU - mas a bytesorrend mint egy x86 CPU-n futo browser eseten). Valojaban az JS TypedArray pont azert van kitalalva, hogy performancia miatt nativ byte szinten is hozzaferj a dolgokhoz, csak innentol ugye a te feleloseged, hogy lehet egy csomo lehetoseg mas-mas platformon.
Title: Re: CoProcessor
Post by: lgb on 2014.September.24. 16:45:56
Quote from: Povi
Na, akkor talán mégis csak ez a megoldás! :-)

Az IEE754 23 biten ábrázolj a mantisszát, de mégis 24 bites a pontossága, mert úgy veszi, hogy a 24. bit az mindig 1. :-) Vagyis 1.011110110... stb. formában. Az AM9511 pedig csak 23 bit pontosságú, szóval nem veszítenék pontosságot (itt ugye 0.111001000 stb, ahol a 2-1 helyiértéken lévő bit mindig = 1.

Felteve, hogy JS Float32 eseten mindenhol a fenti IEE szabvanyt hasznalja, es korrigalod az endian elteres byte order variaciojat elobb :-D
Title: Re: CoProcessor
Post by: Povi on 2014.September.24. 16:46:56
Oké, oké, megértettem mit írtál... :-)
Azt hittem, tuti mindenhol IEEE754 van, de erre a little-big endian dologra nem is gondoltam... :oops:
Title: Re: CoProcessor
Post by: Povi on 2014.September.24. 16:48:52
Azért mondjuk vicces dolog ez a számítástechnika, és szabványosítás: ha valamit kétféleképpen lehet ábrázolni, akkor tuti, hogy lesz két tábor, aki így, a másik úgy ábrázolja... :-)
Title: Re: CoProcessor
Post by: lgb on 2014.September.24. 17:04:09
Quote from: Povi
Azért mondjuk vicces dolog ez a számítástechnika, és szabványosítás: ha valamit kétféleképpen lehet ábrázolni, akkor tuti, hogy lesz két tábor, aki így, a másik úgy ábrázolja... :-)

Nem meglepo, vegulis emberi nyelveknel is igy van ...

Kozben: http://lgb.hu/temp/float32.html (http://lgb.hu/temp/float32.html)

Csinaltam a fentit epp most. Ez JS-bol online generalja le a tablazatot, tehat lehet, mas fog megjelenni adott hw-n mint egy masikon. Lathato, hogy az JS nativ numeric tipusarol a Float32 egybol pontatlanabb. Hozzaferni viszont byte szinten csak ez utobbihoz lehet.
Title: Re: CoProcessor
Post by: Povi on 2014.September.24. 17:21:49
hm...
érdekes táblázat
végül is, ahogy várható, a végtelen "kettedes törtek" (nem is tudom, hogy kéne hívni) esetében lesz pontatlan...
Az viszont érdekes, hogy 0.1-nél felfelé kerekíti a mantissza utolsó LSB-jét.
Title: Re: CoProcessor
Post by: lgb on 2014.September.24. 17:28:51
Quote from: Povi
hm...
érdekes táblázat
végül is, ahogy várható, a végtelen "kettedes törtek" (nem is tudom, hogy kéne hívni) esetében lesz pontatlan...
Az viszont érdekes, hogy 0.1-nél felfelé kerekíti a mantissza utolsó LSB-jét.

Mobil eszkozon kene megnezni, ott divatos ARM proci byte order tekinteteben ha jol remlik pont forditva muxik mint egy x86-os PC.
Title: Re: CoProcessor
Post by: NoP on 2014.September.24. 20:40:55
Mobil eszkozon kene megnezni, ott divatos ARM proci byte order tekinteteben ha jol remlik pont forditva muxik mint egy x86-os PC.

Tessenek parancsolni. :) Apple A7 CPU, mobil Safari.
Title: Re: CoProcessor
Post by: lgb on 2014.September.24. 22:31:34
Quote from: NoP
Tessenek parancsolni. :) Apple A7 CPU, mobil Safari.

Koszi. Erdekes, ez ugyanannak tuniik mint x86-on ... lehet csak CPU nativ adatokra (integer) vonatkozik az endian dolog, es az FPU fromatumokat nem keverik meg ezzel??
Title: Re: CoProcessor
Post by: Povi on 2014.September.25. 19:38:13
Quote from: lgb
http://ep.lgb.hu/jsep/demo.new/ (http://ep.lgb.hu/jsep/demo.new/)

Vigyazat, csak a demo.new-s jo, a sima demo-sban nincs APU kezdemeny se! Na ez a legelemibb, csak a fentebb beszelt Am9511 detektalo rutinra jo stuff, mas cmd-t nem nagyon ismer :) A default disk image-en rajta van a hp13.com is most, minden extra URL param nelkul igy betoltheto. A pascal ki is irja hogy Am9511 detected. Az emulator stop gombbal valo leallitasa utan a "debug ablakban" lehet is nezelodni, az APU: kezdetu sorokra erdemes figyelni nyilvan. Most majd inkabb aztan azokkal a commandokkal szorakozok, amit emlitettel, hogy HP APU-s "verzioja" jelenleg hasznalja.
Ez most hogy áll?
Próbálgattam pl. a lebegőpontos szám kiírását, de butaság jön ki.
   á.00000E+03-at ír ki
persze lehet, hogy az én módosításom hibás... :-)
Title: Re: CoProcessor
Post by: endi on 2014.September.25. 20:23:25
milyen programnál látnátok hasznát ennek a cooproci dolognak?
gondolom a pi kiszámítás nem egy nagy cél :)
viszont komolyabb programba beépíteni, vagy valami komolyabb programot írni ami használja, sok meló, azt senki se fogja csinálni
Title: Re: CoProcessor
Post by: IstvanV on 2014.September.25. 20:28:33
Quote from: endi
milyen programnál látnátok hasznát ennek a cooproci dolognak?
Ezeken (http://enterpriseforever.com/programozas/fraktalok-assemblyben/msg35863/#msg35863) például gyorsíthatna.
Title: Re: CoProcessor
Post by: Povi on 2014.September.25. 20:44:22
Quote from: endi
milyen programnál látnátok hasznát ennek a cooproci dolognak?
gondolom a pi kiszámítás nem egy nagy cél :)
viszont komolyabb programba beépíteni, vagy valami komolyabb programot írni ami használja, sok meló, azt senki se fogja csinálni
Gyakorlati haszna nincs sok, mert mérnöki számításokra ott van pl. a PC, több GHz-cel, beépített koprocival... :-)
Hobbiszinten gondolkodva már van értelme (legalábbis számomra), sokat tanulok a hardver Z80 buszhoz illesztésével (még akkor is, ha nem én találom ki az áramkört, hanem egy más által tervezettet építek meg). Első körben a HiSoft Pascal írtam át (ez is izgalmas dolog volt - visszafejteni annyira, hogy bele tudjak nyúlni), ami már koprocira fordít (már csak a procit várom, amit az ebay-ről rendeltem - amit nagyon remélek, hogy nem egy fake IC lesz), szóval lesz a Földön max. 2 darab EP, ami kihasználhatná ezt, de szerintem a 8 bites hobbiprojektek nem arról szólnak, hogy bármi kézzelfogható értelme is legyen.
De egyébként ahogy István is mondja: pl. Mandelbrot-halmaz rajzolásra lehet használni :-)
Title: Re: CoProcessor
Post by: endi on 2014.September.25. 20:47:39
nem is arra gondolok, hogy olyan értelme legyen, hogy majd valami EP-n kívüli dologban/dologra használjuk
de EP-n "belül"... azért kéne valamire... mert amúgy mi értelme?
Title: Re: CoProcessor
Post by: Povi on 2014.September.25. 20:49:41
Pl. lehetne egy IS-BASIC 2.2, ami használja a koprocit, ha van. Ez már értelmes célnak tűnik, és az összes létező BASIC programra rögtön hatással lenne :-)
Title: Re: CoProcessor
Post by: lgb on 2014.September.25. 21:45:27
Quote from: Povi
Ez most hogy áll?
Próbálgattam pl. a lebegőpontos szám kiírását, de butaság jön ki.
   á.00000E+03-at ír ki
persze lehet, hogy az én módosításom hibás... :-)

Meg sehogy, kb egyetlen command-ot tud csak az a verzio amit a detektalashoz hasznaltal a rutinodban - nem csoda ha hulyseget csinal minden masra :D Amugy, ha emut stoppolod es a debug window-t nezed, valszeg' oda is van irva hogy milyen APU command-okat probaltal amit nem ismer. Az altalam iras alatt levo verzio meg meg syntax error mert eppen restrukturalas alatt all :-( Szoval azt nem tettem ki, el sem indulna az emulacio jelen formajaban ...
Title: Re: CoProcessor
Post by: lgb on 2014.September.25. 21:50:15
Quote from: Povi
Pl. lehetne egy IS-BASIC 2.2, ami használja a koprocit, ha van. Ez már értelmes célnak tűnik, és az összes létező BASIC programra rögtön hatással lenne :-)

Na igen, kerdeses, hogy az IS-BASIC specialis szamabrazolasa (BCD alapu) hogy fer ossze ezzel, ott a konverzio durvabb lehet, mint a pascal eseten, remelhetoleg meg igy is megeri azert majd. IS-BASIC belso szamabrazolasanak teljes megreformalasa sokat dobna (eleve sw-only megoldasban is ugye lassabb mint konkurent BASIC-ek, a BCD hasznalata miatt - igaz, erossege is, mert pontosabb a szamabrazolas, emberi leptek szerint szokasos szamoknal), az viszont gyanitom hogy sokkal bonyolultabb mint csak az adott szamitasnal konvertalni IS-BASIC es APU kozott, majd a szamitas utan vissza ... Ha IS-BASIC eleve az APU formatumaban tarolna a szamot, az meg tobb sebesseget adna (es meg mindig lehetne sw rutin is, ami megcsinalja, ha nincs APU). Bar, mint irtam, az IS-BASIC erossege pont a gyengesege is, hogy kisse nehezen emesztheto (a gep szamara!) de sokszor praktikus celokra pontosabb szamabrazolasi modszert hasznal!

Kar, hogy nincs vmi modern, gyorsabb valtozata az Am9511-nek ami kb compatible. Ui eleg oregecske (kell neki +12V is talan?) es lassu, nem is konnyu szerezni ... Olyan kene ami konyebben elerheto, hogy tobb embernek is lehessen aztan. Sajnos szerintem kicsi a valoszinusege, hogy van ilyen, foleg, ha a kompatibilitas feltetel, marpedig nem artana egy "szabanyos EP co-proci ...".
Title: Re: CoProcessor
Post by: Povi on 2014.September.26. 08:36:09
Quote from: lgb
Meg sehogy, kb egyetlen command-ot tud csak az a verzio amit a detektalashoz hasznaltal a rutinodban - nem csoda ha hulyseget csinal minden masra :D Amugy, ha emut stoppolod es a debug window-t nezed, valszeg' oda is van irva hogy milyen APU command-okat probaltal amit nem ismer. Az altalam iras alatt levo verzio meg meg syntax error mert eppen restrukturalas alatt all :-( Szoval azt nem tettem ki, el sem indulna az emulacio jelen formajaban ...
Csak azért érdekes, mert valamit mégis csak csinál, mert egyébként már forditás alatt le kéne állnia hibaüzenettel, amikor a forráskódban lévő számot alakítja át magának 32 bitesre, ugyanis akkor használja az összeadás rutinokat, de itt nálad legalább lefordul a kód. Valószínűleg a status byte olvasásánál nem 0xff jön vissza... :-)
Title: Re: CoProcessor
Post by: Povi on 2014.September.26. 08:49:10
Quote from: lgb
Na igen, kerdeses, hogy az IS-BASIC specialis szamabrazolasa (BCD alapu) hogy fer ossze ezzel, ott a konverzio durvabb lehet, mint a pascal eseten, remelhetoleg meg igy is megeri azert majd. IS-BASIC belso szamabrazolasanak teljes megreformalasa sokat dobna (eleve sw-only megoldasban is ugye lassabb mint konkurent BASIC-ek, a BCD hasznalata miatt - igaz, erossege is, mert pontosabb a szamabrazolas, emberi leptek szerint szokasos szamoknal), az viszont gyanitom hogy sokkal bonyolultabb mint csak az adott szamitasnal konvertalni IS-BASIC es APU kozott, majd a szamitas utan vissza ... Ha IS-BASIC eleve az APU formatumaban tarolna a szamot, az meg tobb sebesseget adna (es meg mindig lehetne sw rutin is, ami megcsinalja, ha nincs APU). Bar, mint irtam, az IS-BASIC erossege pont a gyengesege is, hogy kisse nehezen emesztheto (a gep szamara!) de sokszor praktikus celokra pontosabb szamabrazolasi modszert hasznal!

Kar, hogy nincs vmi modern, gyorsabb valtozata az Am9511-nek ami kb compatible. Ui eleg oregecske (kell neki +12V is talan?) es lassu, nem is konnyu szerezni ... Olyan kene ami konyebben elerheto, hogy tobb embernek is lehessen aztan. Sajnos szerintem kicsi a valoszinusege, hogy van ilyen, foleg, ha a kompatibilitas feltetel, marpedig nem artana egy "szabanyos EP co-proci ...".
Van ez a SPI / I2C buszos koproci, nem tudom, te ugyanezt linkelted-e már, ezzel lehetne esetleg foglalkozni:
http://micromegacorp.com/umfpu-v3.html
Bár kérdés, vajon gyártják-e még...
Olyan szempontból szerencsésebb, hogy legalább szabványos formátumot használ, a hibája az, hogy nem tudod közvetlenül 8 bites buszra illeszteni.
Viszont ha lesz egy kis időm, szeretném kipróbálni a PIC parallel slave port módját, és aztán PIC-en keresztül lehetne SPI (vagy I2C, vagy soros stb.) port EP-n is. Nem túl elegáns, de nem is rossz. Itt van egy doksi (http://ww1.microchip.com/downloads/en/AppNotes/00579b.pdf) a PSP mód használatáról, elég egyszerűnek tűnik, forráskód is van, elég egyszerű program, egy bájt olvasása és írása a buszra.
Itt van egy érdekes cikk (http://www.ace.tuiasi.ro/users/103/Bind3.pdf) is a PSP módról:
"Every time when the main processor reads or writes data from or to this 
PSP port, an interrupt is automatically generated to the microcontroller central 
processing unit. So, it is very easy to interface one of these microcontrollers to a 
system with main Z80 microprocessor. Well programmed this device can be 
used like a timer, serial port, parallel port, I2C port, SPI port, or we can make 
use of the 10 bit integrated ADC or other peripherals that are in this particular 
PIC microcontroller (like the EEPROM nonvolatile memory block) [9]. It 
should be noted that the Z80 family of peripherals does not contain I2C or 
newer standards!"
Title: Re: CoProcessor
Post by: lgb on 2014.September.26. 10:19:14
Quote from: Povi
Csak azért érdekes, mert valamit mégis csak csinál, mert egyébként már forditás alatt le kéne állnia hibaüzenettel, amikor a forráskódban lévő számot alakítja át magának 32 bitesre, ugyanis akkor használja az összeadás rutinokat, de itt nálad legalább lefordul a kód. Valószínűleg a status byte olvasásánál nem 0xff jön vissza... :-)

Ja :) Amugy pl nem vili, hogy nem letezo APU command-nal mi tortenik. A specifikacio szerint "nem definialt akkor". Az mas kerdes, hogy en meg az elvileg letezo command-okat se tudom :)
Title: Re: CoProcessor
Post by: lgb on 2014.September.26. 10:27:17
Quote from: Povi
Van ez a SPI / I2C buszos koproci, nem tudom, te ugyanezt linkelted-e már, ezzel lehetne esetleg foglalkozni:
http://micromegacorp.com/umfpu-v3.html

Igen ez a a micromegas cuccot mar en is emlitettem, erdekes. Amugy ez allitolag egy sima mikrokontroller, a lenyeg benne az, hogy ok irtak es optimalizaltak kodot, ami aztan "FPU-kent" viselkedik ra. Van amugy benne mas erdekes is, csak emlekezetbol: soros port, A/D atalakito (vagy D/A?), amit igy mind lehetne hasznalni! Viszont, az, hogy ez mikrokontroller, eszembe jutatta, hogy nincs-e vmi open source PIC vagy AVR project, ami egy mezei "filleres" MCU-bol csinal vmi hasonlot. Az ugye egyszerubben beszerezheto akkor es val'szeg olcsobb is lenne :) Plusz, ott modunkban allna valtoztatni, akar pl Am9511 compatible reszt is irni (vagy az ultimate cucc: IS-BASIC float comaptible formatum is! es akkor az IS-BASIC egyszeruen gyorsithato, nem gond a sajat "fura" szamabrazolasi modszere ami fele BCD), vagy tudomisen ... Szerintem egy 8 bites MCU a megfelelo "firmware"-el tudna legalabb olyan gyors lenni mint egy "oskori" Am9511 (valaki pont be is idezett egy linket, hogy Am9511/micromega umFPU ugyben, ott volt talan osszehasonlitas is), es olcsobb is lenne, konyebben beszerezheto, kevesebbet fogyaszt, egyszerubb a tapellatas (+12V az Am9511-nek), stb stb. Sajat MCU-n valo FPU implementacio :) eseten meg lehet gondolkodni eleve pl a 8 bites buszban, SPI helyett. AVR (PIC nem tudom) eseten ugye van azert legalabb integer szorzas, ami sokat segit kulonbozo FPU rutinok hatekony implementalasaban esetleg ...

Visszaterve az umFPU-ra es az SPI-ra: azert vetettem fel meg anno, hogy egy univerzalis SPI interface-t kene epiteni EP-hez. Erre aztan egy rakas SPI eszkoz rakaszthato lenne, kezdve az SD kartyatol :) az umFPU-n at egeszen fura dolgokig: nagyon sok minden van SPI buszos cucc, pl RS232 illeszto, USB, stb, es az SPI busz alacsony vezetekigenye :) [8 bithez kepest] meg aztan egyszerubbe is tenne pl a PCB-t talan. Az SPI busz maga meg mehetne akar tobb MHz-en is, igy EP szamara nem lenne lassabb, mintha parhuzamos, 8 bites busz lenne akar!

Quote
Viszont ha lesz egy kis időm, szeretném kipróbálni a PIC parallel slave port módját, és aztán PIC-en keresztül lehetne SPI (vagy I2C, vagy soros stb.) port EP-n is. Nem túl elegáns, de nem is rossz.

Igen, errol is beszeltunk: oszinten szolva en AVR parti vagyok, nekem a PIC lassu (ugyanazon az orajelen), programozasa kenyelmetlenebb, hw bonyolultabb a programozasahoz, nincs megfelelo open source tamogatasa (windows cuccok kellenek a fejleszteshez, AVR-nel Linux ala egyszeruen domping van a software-ekbol), stb. _VISZONT_, meg kell, hogy valjam, ez a PSP erdekes, es ezert irigy is vagyok, hogy AVR-en nincs ilyen (hmmm, vagy van, csak en nem ismerem, pl mas a neve, ezert nem tunt meg fel?). Csak amiatt gondoltam mar en is a PIC-kel valo megismerkedesre :) Mondjuk AVR-nel is _elvileg_ talan menne, hogy Z80 ir/olvas az egy INT bemenetere az AVR-nek megy, igy gyorsan tud reagalni, kov utasitas akar a Z80 fele a WAIT, igy talan eleg gyors, hogy PSP es hasonlo nelkul is menjen, igaz pl "turbositott EP" eseten ez mar ketseges is lehet (nem emlekszem hany AVR orajelciklis az interrupt kiszolgalasi ido ...).
Title: Re: CoProcessor
Post by: lgb on 2014.September.26. 20:27:06
A fenti novellam melle: kitettem az emu uj verziojat, a szokasos "uj" helyre: http://ep.lgb.hu/jsep/demo.new/ (http://ep.lgb.hu/jsep/demo.new/)

Ebben az eger kutyulgatas mellett jo sok APU fejlesztes is van, lehet probalkozni. Azert olyan programot nem futtatnek vele, amiben _sok_ apu-s cucc van. Azert nem, mert sok debug uzenet van, ha par ezer ilyet megereszt vmi, szegeny browser fejreallhat tole memoriahiannyal stb :-P Szoval a teljes mandelbrot halmaz kiszamolasahoz majd inkabb kiveszem a debug-ot :) Addig viszont marad, mivel jelenleg en sem vagyok biztos benne, meg JavaScript syntax error is lehet akar, elobb fuleltem le egyet oh-oh .... :)

Ami meg ujdonsag az elvileg osszes APU command implementalasan tul (az hogy azok jol mukodnek-e mas kerdes ...). hogy nemi idozites is van benne, Z80 "megallitasaval". Ahol a leiras szerint a szukseges ido egy tartomany, ott persze nem tudom megmondani, valodi APU pontosan mennyi ideig dolgozik (fugg a bemeno parameterektol ...) ott a tartomanybol hasrautesre beirtam egy szamot kb a ketto kozott ranezesre. Nem hinnem, hogy ez problemat okozna, hiszen az emulalt Z80 amugy sem talalkozik wait statusz bittel, tehat mire kov Z80 op jon, kesz a muvelet.

http://ep.lgb.hu/jsep/demo.new/apu.js (http://ep.lgb.hu/jsep/demo.new/apu.js) Amugy ez az APU emulacio konkretan, ha valakit erdekel, de az okozott agykarosodasert amit a fenti cucc megtekintese okoz _nem_ vallalok feleloseget. :) Biztos, hogy sokkal jobban meg lehetne csinalni, lehet en is meg fogom :) Ha egyszer legalabb ez a gyors modszerrel kb megy ...

Ha valakinek van eszrevetele, jelezze, mert kozben a fejlesztoi (csak altalam elerheto) verzioban mar jo sok dolgot atirtam, de jo lenne esetleges bugfixeket is atvezetni oda, mielott annyira maskepp fog kinezni, hogy nem is tudom, abban hogy javitsam :) Vagy irnom kene egy teszt programot. Barcsak lenne igazi APU+EP akkor konyebb lenne osszehasonlitani, hogy mire mit csinal, igy eleg nehezkes a dolog, foleg egyes nem teljesen definialt helyzet eseten, amikor a leirasok se sokat segitenek, hogy akkor mi tortenik ...
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 09:58:13
Quote from: lgb
A fenti novellam melle: kitettem az emu uj verziojat, a szokasos "uj" helyre: http://ep.lgb.hu/jsep/demo.new/ (http://ep.lgb.hu/jsep/demo.new/)

Próbálgatom az új emulátorral a Pascal 1.3-at, de nekem mindig lefagy...
Direkt próbáltam olyan programmal is, ahol nincs string - lebegőpontos szám konverzió egyik irányba se (mert azok is használnák a lebegőpontos rutinokat), és úgy se megy.
Code: [Select]
program proba;
var
  r : real;
  i : integer;
begin
  i := 10;
  r := i*pi;
end.
A sima emulátoron értelemszerűen overflow hibával megáll a szorzás utasításnál, mert a status byte-ot olvasva 0xff-et kapunk, és az overflow bit be van állítva (ezt nézi először).
Ha kiveszem a status byte vizsgálatát, akkor meg lefut a program (az már más kérdés, hogy az r változó értékét kiíratva marhaságot kapunk).

A web emu-ban pedig futtatáskor egyszerűen lefagy...
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 10:53:42
megnéztem a debug-ot:
APU: write data: 0x0
REPEAT: last line was repeated 2 times.
APU: write data: 0xa0
APU: write data: 0x4
APU: write data: 0xd8
APU: write data: 0xf
APU: write data: 0xc9
APU: write data: 0x2
APU: float is internally pop'ed: 3.141592025756836
APU: float is internally pop'ed: 10
AUDIO: stop: audioNode has been unused already
AUDIO: stop: audioCtx has been unused already
Stop emulation

tehát elvileg a két operandust megkapta az APU...
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 10:59:16
10 = 04 a0 00 00
PI = 02 c9 0f d8
szóval a konverzió jó, és ki is küldte az APU-nak
viszont nem látom, hogy a szorzás parancsot is ki küldte volna
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 11:02:21
Quote from: Povi
A web emu-ban pedig futtatáskor egyszerűen lefagy...

Nyiss egy javascript console-t (firefox-on CTRL SHIFT K chrome-ban talan uez, csak K helyett J). Ha kozben vmi javascript errort ir ki oda, az akkor megmagyarazza :-) Ha ilyet latsz, kuldd mar el nekem legyszi. Amugy nem lehetne leforditott, egyszeru programmal (eleg futtatni, nem pascal-ban kell forditani elobb, persze legjobb lenne egy kvazi par byte-os sima exos-5 header program) tesztelni? Mert akkor ha azt odaadod (de lassan irok egyet en is, mert igy tenyleg nehez ...) akkor en is tudom jobban tesztelni :)
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 11:05:33
Quote from: Povi
10 = 04 a0 00 00
PI = 02 c9 0f d8
szóval a konverzió jó, és ki is küldte az APU-nak
viszont nem látom, hogy a szorzás parancsot is ki küldte volna

Hmm, pedig debug window-ban latszania kene ... Ha pl az apu.com -ot betoltod (JSep default disk img-jen rajta van), akkor pirosra valt a kepernyo, jelezve hogy van APU (ha nincs, fekete). Az altalad irt detektalo rutin eredmenyet (A regiszter) irja ki egyszeruen keret szinnek. Ez ilyesmit ir a debug ablakba:

Code: [Select]
APU: write data: 0xef
APU: write data: 0x0
APU: write data: 0x83
APU: write data: 0x0
APU: command 0x6e has been executed, status = 0x0, stack_p diff = -2, TOS = 2, clocks = 89
APU: read data: 0x7a
APU: read data: 0x4d

Lathato, hogy a command-ot is latni kene. Ha nincs ott, akkor a programod vagy ki sem kuldi, vagy az emulatoromban van vmi JS hiba hogy nem jut el addig :D ebben az esetben a javascript console-ban kene latszodnia valaminek (lasd elozo post-omat errol).

A "command ... has been executed" utan azok az adatok ha erdekelne: status az ugye az APU status reg erteke, stack_p diff azt mutatja, hogy a stack allapota mennyit valtozott a command elott es utan, -2, azaz ket byte kiurult (hiszen volt ket operandus, maradt utana 1, de fixed 16 format, ahol egy op 2 byte), a TOS nem a TOS erteket, hanem a pointert ra mutatja, az APU stack szeruseg maga ui egy "ring buffer" szeru strukturaban van implementalva. A clocks az APU clock-ok szama, mint irtam, ahol a specifikacio tartomanyt ad es nem fix erteket, oda hasrautesre beirtam egy szamot a ketto kozott ... Ezt konvertalja (az JSep-ben jelenleg az APU 2.5MHz-esnek van "emulalva") Z80 ciklusokra (egyszeruen APU es Z80 clock kozotti arannyal) es annyi Z80 tstates-t "behazud" az emulatornak, igy kb olyan "erzes", mintha tenyleg wait-elve lett volna addig a Z80.
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 11:10:18
ezt irja ki:

Uncaught TypeError: undefined is not a function

ep.lgb.hu/jsep/demo.new/apu.js?b=1378479743:172
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 11:14:38
BASIC-ben fogok próbálkozni egy kicsit, egyelőre kiküldtem egy PUPI parancsot, arra ez jött ki:
0x02 0xc9 0x0f 0xda
szóval jónak tűnik
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 11:18:11
Quote from: Povi
ezt irja ki:

Uncaught TypeError: undefined is not a function

ep.lgb.hu/jsep/demo.new/apu.js?b=1378479743:172

Hmm, ez erdekes. Firefox-szal kiprobalnad? Az a sor (172-es) ez:

Code: [Select]
var exp = Math.ceil(Math.log2(data));
Tehat en firefox32-n neztem ezt, te gondolom mas browseren (forum szerint chrome). Tehat a chrome nem ismeri a Math.ceil vagy a Math.log2 fuggvenyt, a firefox meg igen, csak ezt tudom saccolni. Ha lehet, tenyleg probald ki legyszi firefox -szal. En meg majd utananezek, mennyire standard ez a ket math rutin, es ha nem az, kitalalok valamit helyette, amit lehetoleg minden browser ismer. Koszi!

UPDATE: igazam volt, ketszer is :) eloszor is, hogy biztos JS hiba lesz, masodszor, hogy a chrome nem ismeri: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/log2 (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/log2) Tanacsom meg mindig az, hogy legyszi firefox-szal probald, en meg persze majd valami kompatibilisebb megoldast talalok oda ki, de az kb estere saccolhato, nem most azonnal.
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 11:20:47
az a baj, hogy Firefox-on sehogy se tudom előcsalogatni a pontosvesszőt (Chrome-on meg a nyitó zárójelet)...
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 11:22:47
egyébként BASIC-ben, Firefox-szal in, out parancsokkal működik a szorzás:
APU: command 0x1a has been executed, status = 0x0, stack_p diff = 4, TOS = 4, clocks = 16
APU: write data: 0x0
REPEAT: last line was repeated 2 times.
APU: write data: 0xa0
APU: write data: 0x4
APU: float is internally pop'ed: 10
APU: float is internally pop'ed: 3.141592502593994
APU: command 0x12 has been executed, status = 0x0, stack_p diff = -4, TOS = 4, clocks = 150
APU: read data: 0x5
APU: read data: 0xfb
APU: read data: 0x53
APU: read data: 0xd0
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 11:28:09
Quote from: Povi
egyébként BASIC-ben, Firefox-szal in, out parancsokkal működik a szorzás:

Aha. Akkor a log2 volt a baj. Na gyorsan atirtam, nezd meg most chrome-mal. Mondjuk ha frissitem az emulatort online, gond lehet hogy a browser becache-elte, szoval fmi forced reload nem arthat :)
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 11:31:29
igy már működik... :-)
már csak a zárójelre kéne valami megoldás...
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 11:31:53
Quote from: Povi
az a baj, hogy Firefox-on sehogy se tudom előcsalogatni a pontosvesszőt (Chrome-on meg a nyitó zárójelet)...

A baj ugye az, hogy emulator szinten raw key code kene, ami PC kbd layout fuggo, ehhez van positional mapping szeruen az EP keyboard. Magyarul, hasznalj US PC kiosztast (magyart kiosztas az az ordog muve ...), es akkor kb ugy kene lennie a gomboknak tobbe-kevesbe, ahogy EP billentyuzetre nezve is latod. Azaz ugye J, K, L gombok utan mi jonne EP-n? Na az jon JSep-vel is, csak eppen ha nem US kiosztast hasznalsz a PC-den az nyilvan bezavar. Sajnos erre megoldas jelenleg nem nagyon van: ha ket kiosztas kozott kulonbseg van, azt egyreszt nehez lenne detektalni, masreszt megoldhatatlan problema, ha valami EP-n shift-el jon, PC-n meg nem, foleg, ha PC-n egyik kiosztason shift-elt, a masikon meg nem. Hiszen a shift allapotat is tovabbadom az EP fele ........

Tehat, US kiosztas PC-n beallit, es akkor EP billentyuzetet ha nezed, shift 8 es 9 a nyito- es zarojel. Ha minden igaz. Magyar kiosztas viszont bekavar, mert mas kodot fog visszaadni ...
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 11:40:15
bill. működik, de újabb hibát találtam... :oops:

225. sor:
 _apu_stack[(_apu_tos - d1) & 0xF] = _apu_look(d2);


Uncaught ReferenceError: _apu_look is not defined


az xchg parancs nem akar működni...
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 11:52:04
Megint JS hiba. :( Sajnos igen, ugye begepeltem sajat kis fejem alapjan, de tesztelni nem teszteltem, nem csoda, hogy kijon par bug. _apu_look8() kene, lemaradt egy 8-as :) Most atirtam. Amugy, ezert is mondtam, hogy ha mar ilyen lelkessen irsz APU-s cuccokat, irhatnal egy sima exos-5 .com -ot, ami kiad minden parancsot :) De ha nem teszed meg, majd en, mert ez igy eleg ego ram nezve, hogy ennyi gond van :D Bocsi. Es ez csak a syntax error, ettol persze lehet logikai hiba is az egeszben, szoval vmi olyan teszt program kene, ami ellenorzi is az eredmenyt mindig.
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 11:58:10
megírom én, de most én mondom azt, hogy estére... :-)
de lehet, hogy egy Pascal progi lesz, lefordítva, legalább nem kell foglalkoznom a szám -> string konverzióval, és legalább a Pascal is le lesz tesztelve
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 12:01:06
Quote from: Povi
megírom én, de most én mondom azt, hogy estére... :-)
de lehet, hogy egy Pascal progi lesz, lefordítva, legalább nem kell foglalkoznom a szám -> string konverzióval, és legalább a Pascal is le lesz tesztelve

Felolem oke, de akkor az a leforditott cucc csak IS-DOS alatt megy majd? Vagy en keverem, hogy melyik pascal IS-DOS-os :) Igazad van amugy, en is lusta voltam asm-ban nekiallni a tesztprogramnak, mert egy egyszeru teszt oke, de kiiratni, haaat, azt hirtelen nem akartam lefejleszteni (szam->string) :-) apu.js elejere odairtam a neved, ha mar segitesz tesztelni :)
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 12:19:20
Quote from: lgb
Felolem oke, de akkor az a leforditott cucc csak IS-DOS alatt megy majd? Vagy en keverem, hogy melyik pascal IS-DOS-os :) Igazad van amugy, en is lusta voltam asm-ban nekiallni a tesztprogramnak, mert egy egyszeru teszt oke, de kiiratni, haaat, azt hirtelen nem akartam lefejleszteni (szam->string) :-) apu.js elejere odairtam a neved, ha mar segitesz tesztelni :)
Nem, ez 5-ös fejlécű programot készít, pont ez a jó benne.

Egyébként érdekes, hogy pl. a SIN(PI)-re 1.87254E-06-t ir ki 0 helyett...
A sinusz függvényhez még nem nyúltam a Pascal-ban (tehát nem az APU SIN parancsa számolja ki), hanem az eredeti szoftveres rutin fut, ami meghívja az APU összeadás, szorzás és osztó parancsait (ez most nem hiba, csak érdekesség - valószínűleg a többszörös oda-vissza konverzió a két formátum között eltorzítja az eredményt).
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 12:21:55
Ha a tesztek sikeresek lesznek, kiveszem a sok debug-ot, mert ugye egy eroteljes APU-s cucc (pl mandelbrot halmaz rajzolas) eseten szepen szetfloodolna a browsert a sok log :) Ennek kapcsan jutott eszembe, hogy esetleg lehetne cheat mode, hogy ultra gyors APU, erdekes lenne majd megnezni mennyivel gyorsabban mandelbrotozik :) ugy. De ezt majd kesobb, elobb a teszt-sorozat :D

Esetleg par custom feature olyan APU parancsokra teve, ami alapbol nem implementalt egy igazi APU-n? Bar az ilyen emulator-only megoldasok mindig veszelyesek, hiszen mason ugyse fog menni, es esetleg kompatibilitasi gondot okoz, ha egy rosszul megirt program hasznal egy nem letezo command-ot (ami JSep-n esetleg valami tartos beallitast modosit ...), de aztan folytatna massal.
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 13:22:29
Quote from: Povi
Nem, ez 5-ös fejlécű programot készít, pont ez a jó benne.
Cool!
Quote
Egyébként érdekes, hogy pl. a SIN(PI)-re 1.87254E-06-t ir ki 0 helyett...
A sinusz függvényhez még nem nyúltam a Pascal-ban (tehát nem az APU SIN parancsa számolja ki), hanem az eredeti szoftveres rutin fut, ami meghívja az APU összeadás, szorzás és osztó parancsait (ez most nem hiba, csak érdekesség - valószínűleg a többszörös oda-vissza konverzió a két formátum között eltorzítja az eredményt).
Na igen, ez valoszinu. Amugy az APU emulacio lehet, tobb ponton sem helyes, foleg ami a status register beallitasat illeti, pl underflow esemeny pontosan mikor van. Ez utobbit en igy kezeltem le: ami az "underflow gap-be esik" (az a tartomany ami nullat korulveszi, es az adott floating point szamabrazolasanal csak nullakent abrazolhato) azt detektalom. Meghozza ugy, hogy a javascript push-olni akar egy float-ot, ami javascript nativ adatkent nem nulla, am APU float formatumban mar ez, ekkor allitom azt be. Stb, hasonlok. Viszont ez nalam minden float internal push muveletre igaz, lehet igazi APU-nal nem minden command eseten allitodik be. Es hasonlok ...
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 13:33:01
no igen, meg amire még nem tér ki a doksi, de nagyon kíváncsi vagyok, hogy vajon a float -> integer konverzió hogyan megy végbe?
kerekít, vagy csonkol?
ez is majd akkor derül ki, ha megérkezik végre a proci
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 13:47:00
Quote from: Povi
no igen, meg amire még nem tér ki a doksi, de nagyon kíváncsi vagyok, hogy vajon a float -> integer konverzió hogyan megy végbe?
kerekít, vagy csonkol?
ez is majd akkor derül ki, ha megérkezik végre a proci

Jaaa, jut eszembe, a teszt program azert is erdekes: JSep tesztre es real APU teszre is jo :) Tehat a "ket legyet egy csapasra" dolog. Akkor az osszes command-on kivul en mindenkeppen beletennek pl olyat, hogy SMUL/SMUU es DMUL, DMUU elojeles/nem elojeles kombinaciok, meg mindenfele hibat okozo esetet, hogy uaz lesz a status valodi es emulalt APU-n, stb. Az erdekes az, hogy guglival talalni sok mindent az Am9511-rol, meg se sikerult semmit talalni, hogy barki irt mar volna emulatort, vagy teszt programot hozza, akarmit ...
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 15:47:02
úgy tűnik, máris találtam egy hibát... ::oops:

töröltem először az APU regisztereit: kiküldtem az adatportra 16-szor 0x00-t

ezután a TOS-ba beírtam egy 32 bites számot (0x04 0x03 0x02 0x01)

kiváncsi voltam az APU regisztereire:

kiolvastam és kiírattam a TOS-t (port olvasás, értékének kiirása hexa-ban, majd ezt még háromszor megismétlem).

majd adtam egy POPF (0x18) parancsot

ezután megint kiirattam a TOS-t, és igy tovább...

ezek után ezt az eredményt kaptam:
04 03 02 01
00 00 00 00 
04 03 02 01
00 00 00 00

ha jól gondolom, ezt kellett volna:
04 03 02 01
00 00 00 00
00 00 00 00
00 00 00 00
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 16:11:19
Quote from: Povi
úgy tűnik, máris találtam egy hibát... ::oops:

Oszinten szolva eppen rohanok, igy nincs idom megemeszteni ezt estig, amde egy fontos dolog: az APU stackjerol nekem a specikacio alapjan az jott le hogy cirkularis, azaz ha POP-olsz vmit, valojaban ahogy kell a TOS az alatta levo elemre mutat (ami a NOS volt) am a regi ertek nem tunik el, hanem a verem legaljan lesz. Ui csak csak a veremmutatot allitja, a 16 byte meg "korbe er" tehat nem olyan mint a Z80 eseten a stack pl (illetve vegulis olyan, mert 64K utan az is korbe er :) ) Nem tudom ez valaszt ad-e a kerdesre, este meg atgondolom. Na megyek is :)

Masreszt, JavaScript console-t kersz, es beirod a legalso sorba hogy _apu_stack majd enter billencs. Akkor latod az APU stack-et. Az _apu_tos mutatja (annak erteket is lekerdezheted az _apu_tos beirasaval), hogy ebbol melyik elem a TOS, de mint mondtam, valojaban a stack-et itt inkabb mint egy kort kell elkepzelni, tehat a stack eleje es vege "ossze van ragasztva". Azaz, ha az _apu_tos 15-on all (utso elem), akkor push utan 0 lesz az erteke, pop es utana pedig ujra 15. Ha megnezed az apu.js -t akkor az _apu_pop8() es az _apu_push8() (push/pop egy byte) annyit csinal, hogy a (megfelelo sorrendben!) tos-t noveli/csokkenti, adatot beir. Regi adathoz (pop eseten pl) viszont nem nyul, az a verem "melyen" megtalalhato meg mindig!
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 16:15:34
na, ezt most nekem is értelmezni kell, de most úgy látom, mintha én értettem volna félre valamit, szóval, lehet, hogy rosszul értelmeztem a dolgot, és mégse hibát találtam... :oops:
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 16:18:13
Quote from: Povi
na, ezt most nekem is értelmezni kell, de most úgy látom, mintha én értettem volna félre valamit, szóval, lehet, hogy rosszul értelmeztem a dolgot, és mégse hibát találtam... :oops:

Bocs, kozben editaltam is a hozzaszolasomat :) Nade most mar tenyleg megyek, bar ez erdekesebb mint 2 orat vezetni, ami most jon nekem :D
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 20:14:09
Amugy talan pont te ajanlottad ezt: http://www.joelowens.org/z80/am9511algorithms.pdf (http://www.joelowens.org/z80/am9511algorithms.pdf)

Nezd meg pl a POPS leirasat. the previous TOS rotates to the bottom of the stack. Szoval ez es hasonlok alapjan (bar igy nyiltan nem irtak le) gondoltam, hogy persze nem ugy kell elkepzelni, miszerint pop/push utan mindig tologatjak a memoriat. A papiron rajzolt stacknek van alja es teteje csak szemleltetes, ugy kell elkepzelni (z80-on is!), mint pl egy orat, ahoi a mutato a stack pointer. Mivel a pop kivesz ugyan vmit, de _nem_ ir a memoriaba, a stackban az ott marad, csak mivel a stack pointer tovabbmegy hozza kepest "negativ" iranyban van mar az az adat, tehat az egyszeru pelda alapjan ugy latszik mintha a stack aljara kerult volna. Sokkal jobb szemleltetes, az oras pelda, nincs a stacknek alja, korbeer. Z80-nal is push-olsz egy erteket, ha aztan pop-olod, megkapod, de ha utan meg egy "csomoszor" pop-olod ujra megkapod, hisz a stack pointer ujra odaer egyszer csak, miutan "korbeert" a memorian. Csak ugye senki nem szokott tobb tizezer dolgot pop-olni z80-nal, de az APU 16 byte-os stack "keruleten" ez joval hamarabb feltunik :)
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 21:10:11
Közben rájöttem, mi volt az, amit én nem értettem...

Úgy gondoltam, hogy a dataport olvasásával mindig csak a TOS-t tudom kiolvasni, tehát ha 5 byte-ot olvasok, akkor az 5. ugyanaz lesz, mint amit először olvastam.
Ebből adódott a félreértésem...
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 21:13:51
Viszont úgy néz ki, most tényleg találtam valamit... :oops:

Csináltam egy NAGYON egyszerű tesztet:
http://ep.lgb.hu/jsep/demo.new/?snapshot=http%3A%2F%2Fbeac.uw.hu%2Ftest7.ep128s&autostart=yes

csak egy ENTER-t kell nyomni az indításhoz

a parancsokat decimálisan kell beadni

próbáld ki ezt: 26 (PUPI)
majd 03 (COS)

a TOS-ban -1-nek kéne lennie: 0x81 0x80 0x00 0x00

ehelyett 0x80 0xff 0xff 0xff lesz

megint előjött az a hiba (alulról közelíti a kettő hatványát), amit már egyszer írtál
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 21:22:16
persze lehet, hogy kerekítési hiba, mert 00-ra pontosan 1-et ad (0x01 0x80 0x00 0x00)
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 21:32:55
Sajnos tartok tole, hogy a hiba nem ilyen egyszeru ... A problema az, hogy ha JS console-ba pl beirod: Math.cos(Math.PI)) akkor helyes valaszt kapsz, azonban az JS adattipus 64 bites float, raadasul lehet, vigyazni is probalnak ilyenekre. A PUPI a PI-t ugy nyomja stack-be, hogy a PI-t kozeliti (vegulis minden csak kozeliti ... a lenyeg hogy joval pontatlanabbul). Ha a PI-t lenyomjuk APU-nak, majd kerunk egy COS-t, akkor a PI-tol kisse eltero erteket hasznal, es mivel a cos-t viszont JS float-ra vegrehajtva csinalja, latszik mar a kulonbseg. Szoval igen, ez kerekitesi hiba, es valojaban nem az a nomralizacios problema ami volt egyszer nalam tenyleg. Ki kene deriteni, hogy igazi APU mit csinal ilyenkor. Sajnos lehet, hogy pontos APU emulaciohoz majd emulalni kene ahogy o dolgozik, es nem JS szinten csinalni ezeket, ahol az JS "tulzott pontossaga" mar problema barmilyen vicces is. Mellesleg a PUPI es erdekes tema. Nem tudom ugyanis, hogy egy igazi APU egesz pontosan mit tol le. Ugyanazt, amit en kitalaltam, vagy a mantissa pl kulonbozok a legkisebb helyiertekben mondjuk?

Szoval ezt lehet hibanak hivni, viszont akkor elvi hiba. Az APU pontos mukodeset (COS-t ugy szamolja ki ahogy az APU, ne hivja az JS Math.cos()-t) megvalositani nem lenne egyszeru annyira.

Kicsit mas tema: visszaterve a stack-hez: ami PDF volt, erdekes modon APU neha megsemmisiti a stack melyebb reszen levo dolgokat, gondolom azert, mert pl COS stb kiszamitasahoz kell neki temporary tarolohely. Na ez egyaltalan nincs emulalva, es kulonben sincs info, pontosan mit tesz oda amivel megsemmisiti ... Mivel a specifikacio szerint is kb undefined hogy mi lesz ott, veguils nem szabad szamitani ra, es az elozo ertek megtartasa is belefer az undefined-be :D Erdemes a PDF-en megnezni az egyes APU command-oknal a stack abrakat ... Ahol at van huzva, az jelzi, hogy annak erteke elveszik mert az APU ideiglenes atmeneti szamitasoknal (mikozben kiszamolja a COS-t pl) hasznalja.
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 21:49:23
úgy tűnik, tényleg kerekítési hiba lesz SIN(2pi)-re 0xeb 0xa2 0x21 0x68 az eredmény a 0 helyett
ezzel a parancssorral lehet előcsalni:
10, 23, 16, 26, 18, 02
EXP, PTOF, FADD, PUPI, FMUL, SIN
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 21:59:37
Quote from: Povi
úgy tűnik, tényleg kerekítési hiba lesz SIN(2pi)-re 0xeb 0xa2 0x21 0x68 az eredmény a 0 helyett

Ujra felmerul a kerdes, mit csinal az igazi APU :)
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 22:07:59
A leírás szerint a négyzetgyök kivételével mindent Chebyshev polynomials módszerrel számol ki.
A szinus és koszinusz esetében 6 tagú a sorozat.
Title: Re: CoProcessor
Post by: lgb on 2014.September.29. 22:10:47
Quote from: Povi
A leírás szerint a négyzetgyök kivételével mindent Chebyshev polynomials módszerrel számol ki.
A szinus és koszinusz esetében 6 tagú a sorozat.

Ja, csak kinek van kedve ezt lekodolni JS-ben :-D
Title: Re: CoProcessor
Post by: Povi on 2014.September.29. 22:15:34
Szerintem nem is kell, ez legyen a legnagyobb gond, hogy nem túl pontos... :mrgreen:
Title: Re: CoProcessor
Post by: Povi on 2014.September.30. 18:56:11
még nem teljes teszt, de érdekes...
http://ep.lgb.hu/jsep/demo.new/?disk=http%3A%2F%2Fbeac.uw.hu%2Ffloppy_a2&mem=128&zt=no&autostart=yes&skiplogo=yes

a test.com fájlt kell indítani
Title: Re: CoProcessor
Post by: lgb on 2014.September.30. 19:38:42
Quote from: Povi
még nem teljes teszt, de érdekes...
http://ep.lgb.hu/jsep/demo.new/?disk=http%3A%2F%2Fbeac.uw.hu%2Ffloppy_a2&mem=128&zt=no&autostart=yes&skiplogo=yes

a test.com fájlt kell indítani

Kiraly, alakul :D Azert en varom mar, hogy igazi APU-n is megnezzuk, az mit csinal :) Mindenesetre ha legalabb kb csinal vmit, es nem syntax error az mar jo eredmeny az emulatoromban igy elsore (na jo nem elsore mert volt mar par kor). Az sqrt kapcsan: igazbol nem derul ki mindig leirasbol, hogy mit csinal az APU hibas adatok eseten. Marmint pl -2 negyzetgyoke. Az ok, hogy hiba a status byte-ban, de mi lesz az eredmennyel? En pl itt azt vettem, hogy megcsinalja mintha pozitiv lenne (2) de beallitja a status-ban a megfelelo bitet. Mert ugye hiba bit eseten az eredmenyt akkor sem szabad "nezni" ui akkor az nem minosul validnak. A leirasban nehany command-nal kiternek arra mi lesz a stackben ha hibas az input, de sajna nem mindenhol ...
Title: Re: CoProcessor
Post by: lgb on 2014.September.30. 20:25:55
Kozben gondolkodtam ... Az AM9511 jo, dehat nehez beszerezni, kell neki +12V, egyebek, volt errol mar szo. Biztos, hogy nincs vmi 8 bites kornyezetben egyszeruen hasznalhato FPU? Az um-FPU elso korben kiesik mert SPI, most a kulcsszo, hogy egyszeruen bekotheto, mint a "jo oreg APU (9511)". Azt olvasni, hogy az Intel is licencelte es talan 8231 vagy hasonlo neven arulta. Az ha teljesen kompatibilis, szinten jo lenne, foleg, ha pl egyszerubb beszerezni, mint AMD-s tarsat. Pl viszont van 8232 is az inteltol, elonyei hogy 64 bites precizitas, meg IEEE 754 szerinti. Hatranya, hogy kb alapmuveletek vannak, tehat ilyen cos/sin stb az nincs. Adatlap szerint sajna ennek is kell +12V, pedig rulZ lenne, ha nem kene.

Igazabol nem tudom, van-e mas ertelmes lehetoseg ... A 8087 stb elvetve, tulsagosan x86 centrikus. Habar erdemes lehetne jobban megnezni, hatha megy vhogy. Ha jol remlik, vmi prefix byte alapjan ismeri fel, hogy neki szol vmi, tehat ugye nem az x86-os CPU kozi vele egy porton, ahogy pl az EP/APU eseten. Nem tudom ezt mennyire lenne bonyolult athidalni esetleg, maskepp kezelve, es eszszeru komplexitas aran megoldhato-e ...
Title: Re: CoProcessor
Post by: Zozosoft on 2014.September.30. 20:53:39
Quote from: lgb
Biztos, hogy nincs vmi 8 bites kornyezetben egyszeruen hasznalhato FPU?
Én semmit nem találtam.
12V nem olyan gond, manapság pár dollárért lehet kapni kész 12V Step-Up modult.
Title: Re: CoProcessor
Post by: lgb on 2014.September.30. 21:00:39
Quote from: Zozosoft
Én semmit nem találtam.
12V nem olyan gond, manapság pár dollárért lehet kapni kész 12V Step-Up modult.

Igazabol nem is a 12V zavar feltetlen, de mondjuk a fogyasztasa is jelentos lehet. Viszont hiaba almodok CMOS verziorol ...
Title: Re: CoProcessor
Post by: Povi on 2014.September.30. 22:50:51
Arra én is kíváncsi leszek, milyen lesz igazi APU-val, azért is írtam kérdőjeleket egy csomó helyre (pl. a PI helyére), mert nem tudom, az igazi "vas" milyen eredményt kell, hogy adjon.

Meg hogy vajon lesznek-e olyan kerekítési hibák, mint az emulációban (pl. gyök kettő a négyzeten nem kettő (0x02 0x80 0x00 0x00), hanem egy kicsit alatta (0x01 0xff 0xff 0xff), vagy pl. amik a SIN és COS függvények esetén előjönnek... :-)

Az is érdekes, hogy log(125)/log(5)-re pontosan kijön a 3, de ln(125)/ln(5)-re már nem...

Na és igen, az is kérdés, vajon a hibás argumentumok esetén (pl. negatív szám gyöke) mi lesz a TOS-ban. Az ilyen helyekre "xx xx xx xx"-t írtam, mint "expected" eredmény.

Hogy van-e más koproci... Én is csak az Intelről tudok, de az egy az egyben ugyanaz, mint az AMD, szóval nem játszik... Az Am9512 (ami már IEEE-574 komp.) nem is kapható... Legalábbis ebay-en és aliexpress-en sincs eladó, miközben Am9511 rengeteg van (ami reméljük, nem fake...).

Más rendelésem Kínából ma érkezett, ez alapján legkésőbb a jövő hétre várható, hogy megérkezik a koproci... :-)
Title: Re: CoProcessor
Post by: Povi on 2014.October.01. 18:41:19
első sebességteszt (csak emulátoron), Pascal-ban
sin(1) kiszámolása 2000x  koproci nélkül kb. 11.5 mp
sin(1) kiszámolása 2000x koprocival (web emu) kb. 2.2 mp

egyelőre nem sok, kb. 5x sebesség növekedés
bár az is igaz, itt most van 2000 konvertálás is APU float és Pascal float formátum között, bár arányaiban nem tudom, mennyit nyom a latba, de az ENTERPRESS szerinti 50x gyorsulástól még messze vagyunk... :mrgreen:
Title: Re: CoProcessor
Post by: lgb on 2014.October.01. 23:32:43
Quote from: Povi
bár az is igaz, itt most van 2000 konvertálás is APU float és Pascal float formátum között, bár arányaiban nem tudom, mennyit nyom a latba, de az ENTERPRESS szerinti 50x gyorsulástól még messze vagyunk... :mrgreen:

Az ugye atlag volt ott is, illetve, ott az IS-BASIC-hez hasonlitottak, aminek a szamabrazolasa erdekes BCD alapu, es lassabb is emiatt (bar human szempontbol neha jobb - marmint a szamabrazolas es a vele kapott ponotsabb embereknek ismerosebb ertekek, nem a lassusag a jobb persze). Ha most pascal nativ szamitas vs APU, akkor a sebessegek aranya talan nem lesz olyan jo mar mint IS-BASIC vs APU eseten mertek ... Azert is lenne jo egy sajat FPU (almodozzunk), ahol van IS-BASIC altal hasznalt formatum, es igy egyszeru is lesz az atiras, meg gyorsabb is lesz :D Ok, most megyek, es beveszem a gyogyszerem :)

Masreszt a kerdeses cikkben a szinuszra pont 24-szeres szorzot adtak csak, nem 50-szerest az APU javara (igaz ez is tobb, amit te mertel). Az ott levo tablazat szerint amugy SQRT-nel durva a kulonbseg :)
Title: Re: CoProcessor
Post by: Povi on 2014.October.08. 08:28:54
Na, tegnap egyébként megjött a koproci is, de összeraktam, és nem működik...

Persze lehet, hogy én rontottam el valamit, de az is igaz, hogy néha az exdos-kártyát se látja a gép. Szóval akár kontakt hiba is lehet, osszciloszkóp kéne szerintem a rendes hibaelemzéshez.

Viszont gyanús, hogy hamis chip lehet, mert a tetején tűéles felirattal van az AMD logó és a megírás, míg a chip alján teljesen más technikával készült, elmosódott PHILIPPINES felirat olvasható. Nem hinném, hogy ugyanazon  a gyárban két különböző technológiával vittek volna feliratot egy IC tokra. Meg persze azt is jó lenne kideríteni, vajon az AMD-nek volt-e IC gyára a Fülöp-szigeteken a 80-as években... :-)

Majd rakok föl fotót.

A következő terv viszont a PSP lesz, PIC MCU-val.
Title: Re: CoProcessor
Post by: Z80System on 2014.October.08. 08:45:46
Mi az a PSP ?
Title: Re: CoProcessor
Post by: Zozosoft on 2014.October.08. 09:10:25
Quote from: Povi
osszciloszkóp kéne szerintem a rendes hibaelemzéshez.
Egy TTL szonda is sokat segíthet, pl a port műveletekre generálódik select jel?
Ha nézed a portokat bármi olvasható? Úgy alapvetően csak a Pascallal nézted, vagy gépi kódban próbálva? Hiszen lehet, hogy az előre megtippelt kód nem működik a valódin :oops: Időzítés, stb gondok...

Quote
Viszont gyanús, hogy hamis chip lehet, mert a tetején tűéles felirattal van az AMD logó és a megírás
Ez mondjuk annyira nem lep meg, Kína...
Viszont attól még lehet valódi chip, csak mondjuk nem 3MHz-es, hanem kevesebb...
Milyen órajelen nézted?

Quote
AMD-nek volt-e IC gyára a Fülöp-szigeteken a 80-as években... :-)
Szerintem tuti volt, akkoriban mindenkinek ott volt gyára, Zilognak is :-)
Title: Re: CoProcessor
Post by: Povi on 2014.October.08. 09:13:30
Quote from: Z80System
Mi az a PSP ?
Parallel Slave Port mode.
Az a lényeg, hogy a PIC gond nélkül illeszthető a Z80 adatbuszához, és a PIC-ben lévő programtól függ, hogy mit kezdjen a Z80-tól kapott adatokkal. Pl., hogy kiküldje az SPI, vagy I2C portra az adott bájtot... :-)
Title: Re: CoProcessor
Post by: Povi on 2014.October.08. 09:17:45
Quote from: Zozosoft
Egy TTL szonda is sokat segíthet, pl a port műveletekre generálódik select jel?
Ha nézed a portokat bármi olvasható? Úgy alapvetően csak a Pascallal nézted, vagy gépi kódban próbálva? Hiszen lehet, hogy az előre megtippelt kód nem működik a valódin :oops: Időzítés, stb gondok...
Ez mondjuk annyira nem lep meg, Kína...
Viszont attól még lehet valódi chip, csak mondjuk nem 3MHz-es, hanem kevesebb...
Milyen órajelen nézted?
Szerintem tuti volt, akkoriban mindenkinek ott volt gyára, Zilognak is :-)
Órajel: az IC elvileg 3 MHz-es, 2 MHz-cel hajtottam meg (persze itt jó lenne a szkóp, vagy egy freki mérő, megnézni, hogy egyáltalán kap-e órajelet).
Végignéztem BASIC-ből az összes portot (hátha a címdekódolót kötöttem rosszul), de mindenhol 255 jött.
A próba egyébként annyi volt, hogy kiküldtem a parancsportra egy PUPI parancsot (Push PI), és visszaolvastam az adatportot.

arra gondoltam, hogy ki kéne próbálni, hogy a buszmeghajtóra LED-eket kötni, és megnézni, hogy a port irás működik-e. Ez vajon jó ötlet a tesztelésre?
Title: Re: CoProcessor
Post by: Zozosoft on 2014.October.08. 09:37:02
Quote from: Povi
arra gondoltam, hogy ki kéne próbálni, hogy a buszmeghajtóra LED-eket kötni, és megnézni, hogy a port irás működik-e. Ez vajon jó ötlet a tesztelésre?
Erre való a TTL szonda, csak odaérinted a hegyét, és látod, hogy 0,1, vagy változó.
TTL Proba, Logic Probe, TTL teszter, Logikai teszter, ilyesmi neveken keresd, vehetsz készen, csináld magad kitben, vagy találsz rajzot, és megcsinálod magad.
Nekem ilyen van, már több mint 20 éve:
[attach=1]

Az fontos, hogy TTL-t tudjon, nekünk EP-hez az kell.

Ha mondjuk egy címkiválasztójelről van szó, akkor azt látni, hogy alapból piros, azaz 1, majd az IN/OUT hatására felvillan a sárga.
Title: Re: CoProcessor
Post by: Z80System on 2014.October.08. 09:43:13
Quote
Az a lényeg, hogy a PIC gond nélkül illeszthető a Z80 adatbuszához,

Mert most nem gond nélkül van ?


Quote
és a PIC-ben lévő programtól függ, hogy mit kezdjen a Z80-tól kapott adatokkal. Pl., hogy kiküldje az SPI, vagy I2C portra az adott bájtot... (http://enterpriseforever.com/Smileys/phpbb/ds_icon_smile.gif)

De ez most mitől érdekes, minek küldené ilyen portokra,
ki kell számolja, aztán visszatolja valahogy a z80 -nak, nem ?
Title: Re: CoProcessor
Post by: Zozosoft on 2014.October.08. 09:45:54
Quote from: Z80System
De ez most mitől érdekes, minek küldené ilyen portokra,
Itt korábban emlegettek valami újabb koprocit, amivel csak az a baj, hogy SPI buszos. Na ahhoz küldené.
Title: Re: CoProcessor
Post by: Z80System on 2014.October.08. 09:57:44
Quote
 Na ahhoz küldené.

Jaaa ... nem gondoltam hogy egy kooprocinak kell egy külön mc csak hogy átdobja neki az anyagot ...
Title: Re: CoProcessor
Post by: lgb on 2014.October.08. 10:44:52
Quote from: Z80System
Mert most nem gond nélkül van ?
Ez a PSP vagy mi dolog PIC-en amennyire en tudom (AVR-ezek neha, PIC-heznem ertek, szoval tevedhetek is): tegyuk fel, hogy szeretnel egy MCU-t kotni az EP buszara, pl adott I/O cimen dekodolva, miegymas, es kuldenel OUT-tal neki valamit. Ugye a problema az, hogy esetleg az MCU "eppen nem er ra", vagy "tul lassu" ahhoz hogy Z80 kapott adatot fogadja, hiszen az csak kis ideig van a buszon, utana Z80 megy tovabb, mar vmi tok mas lesz a buszon (akar a kov opcode olvasott byte-ja, akarmi). Ez a PSP amennyire en ertem azt tudja pl, hogy "megjegyezi" a kerdeses adatot (latch-eli), igy az MCU (itt PIC) raer kesobb megnezni kesobb is. Na persze, ha annyira lassu az MCU-don futo program, hogy kozben jon masik byte is, az mar baj :D A masik lehetoseg ilyesmi nelkul: eleg gyors MCU kell, eleg gyors programmal, vagy WAIT-elteted a Z80-at, hogy az MCU-nak legyen ra ideje reagalni stb. Amirol szo volt PSP kapcsan, hogy PIC tud ilyesmit, mig - amennyire tudom - AVR pl nem, es bar en nagyon AVR parti vagyok, ez azert plusz pont a PIC javara :)
Title: Re: CoProcessor
Post by: lgb on 2014.October.08. 10:50:47
Quote from: Z80System
Jaaa ... nem gondoltam hogy egy kooprocinak kell egy külön mc csak hogy átdobja neki az anyagot ...

Azert, mert az meg egy SPI buszos FPU szeru entitas (valojaban egy MCU az is, csak eleve fel van programozva - marmint ugye most az uM-FPU nevu IC-rol van szo, mar nem az APU-rol!), viszont eredendoen arra terveztek, hogy MCU-s projectekhez illeszd,  ahol szokas intenziv SPI hasznalat peldaul. Ha EP-be akarod tenni, akkor EP-nek tudnia kene SPI-t, software-esen is lehetne de az azert kemenyen lassu lenne, ezert kell egy EP-busz - SPI illeszto, ami legegyszerubb formajaban egy MCU (az mas kerdes, hogy pl CPLD-bol jol meg lehetne csinalni, es pl az SD cartridge voltakeppen pont ez: egy SPI busz - EP illeszto - jo is lenne, ha sima SPI buszt adna tovabb SD kartya meghajtas mellett, es igy mas SPI-os eszkoz kozvetlenul az EP-re akaszthato lenne, SPI-os eszkozokbol ugyanis van kb minden, meg hw-es mp3 decoder is ...)
Title: Re: CoProcessor
Post by: Povi on 2014.October.08. 17:02:37
Ilyen lett végül a koprocesszor-kártya:
Title: Re: CoProcessor
Post by: Z80System on 2014.October.08. 17:05:59
De most akkor műx vagy nemműx ?
Title: Re: CoProcessor
Post by: Povi on 2014.October.08. 17:14:57
nem
Title: Re: CoProcessor
Post by: Z80System on 2014.October.08. 17:22:26
Egy ilyen próbapanel összerakáskor bármi baj lehet ... kéne szerezz egy műszert, vagy egy olyan tesztert amit zozo mutatott (bár nemtom az hogy műxik, de ha zozo mondja, akkor muxik),

mindenesetre azt mindenképp meg kéne nézzed hogy tápok odaérnek -e, és hogy jelek (freki) vannak -e az adott lábakon, ahol kéne legyen nyüzsi ...

azt ha minden klappol, akkor érdemes agyalni, hogy mér nem klappol mégse ... nem ?
Title: Re: CoProcessor
Post by: Povi on 2014.October.08. 17:29:14
Tápot egy kiszuperált AT tápból kapott (ott ugye van 5V és 12V is). Feszültséget kapott, azt ellenőriztem.
Title: Re: CoProcessor
Post by: lgb on 2014.October.08. 17:40:53
Quote from: Povi
Ilyen lett végül a koprocesszor-kártya:

:) Ez nem kartya, hanem Kirchoff-pok :)
Title: Re: CoProcessor
Post by: Povi on 2014.October.08. 17:43:39
Quote from: Z80System
Egy ilyen próbapanel összerakáskor bármi baj lehet ... kéne szerezz egy műszert, vagy egy olyan tesztert amit zozo mutatott (bár nemtom az hogy műxik, de ha zozo mondja, akkor muxik),

mindenesetre azt mindenképp meg kéne nézzed hogy tápok odaérnek -e, és hogy jelek (freki) vannak -e az adott lábakon, ahol kéne legyen nyüzsi ...

azt ha minden klappol, akkor érdemes agyalni, hogy mér nem klappol mégse ... nem ?
Magával a próbapanellal nem lehet gond, legalábbis nem hiszem, hogy azért nem megy, mert próbapanelon van megépítve. MCU-s áramköröket elég sokat LEGO-ztam már így össze, azokkal se volt gond, sőt a neten elég sok diy z80 projekt kering, breadboard-on megépítve, pl. ez:
http://2.bp.blogspot.com/-Dr6kaCygJe4/UOmKoL62nJI/AAAAAAAAA_k/hOXVlVt42pw/s1600/dscf0016.jpg
(direkt elrettentő példának rakom ezt, de ha ez működik, akkor az enyémnek is kéne :-))
Title: Re: CoProcessor
Post by: Z80System on 2014.October.08. 17:53:18
Nem is azt mondom hogy nem lehet,

hanem hogy csak egy kábel legyen szakadt, vagy nem jól csatlakozó ... oszt nemmegy.

Ezért kéne megnézni, hogy lüktet -e mindenhol ...
Title: Re: CoProcessor
Post by: lgb on 2014.October.09. 20:48:00
Azota sincs hir? :( Esetleg ha szimulalod neki, tudomisen, EP-rol lehuzod, aztan fixen gnd-re vagy vcc-re kotod a megfelelo dorokat, hogy szumlaljon egy I/O muveletet, es kozben nezni, hogy az APU kornyeken a megfelelo jelek vannak-e es minden megvan-e.
Title: Re: CoProcessor
Post by: Povi on 2014.October.09. 21:16:12
Azota sincs hir? :( Esetleg ha szimulalod neki, tudomisen, EP-rol lehuzod, aztan fixen gnd-re vagy vcc-re kotod a megfelelo dorokat, hogy szumlaljon egy I/O muveletet, es kozben nezni, hogy az APU kornyeken a megfelelo jelek vannak-e es minden megvan-e.
Ma nem volt időm foglalkozni vele, és 7végén se lesz, szóval egyelőre türelem... :-)
Még lehet, hogy Zozóhoz is elvinném, megnézni azzal a TTL probe-bal (csak Zozo még nem tud róla :-)).
A másik ötletem még az, hogy esetleg egy PIC-re kötném (ami pedig egy LCD display-re lenne kötve), és azzal tesztelném...
Title: Re: CoProcessor
Post by: lgb on 2014.October.09. 22:47:57
Ma nem volt időm foglalkozni vele, és 7végén se lesz, szóval egyelőre türelem... :-)
Még lehet, hogy Zozóhoz is elvinném, megnézni azzal a TTL probe-bal (csak Zozo még nem tud róla :-)).
A másik ötletem még az, hogy esetleg egy PIC-re kötném (ami pedig egy LCD display-re lenne kötve), és azzal tesztelném...

Az, hogy a cimdekodolas stb jo-e egyszeruen ellenorizheto, kosd az APU adatvezetekeit vmi mintaban Vcc-re es GND-re, aztan EP-n olvasd be a portot, annak kell kijonnie. Csak vigyazz OUT nehog legyen, mert nem fog orulni ugye :)
Title: Re: CoProcessor
Post by: Povi on 2014.October.22. 16:30:57
A következő tervem az, hogy a koprocit összekötöm egy PIC MCU-val, és úgy tesztelem, az eredményt (a koprociból olvasott byte-okat) pedig egy LCD kijelzőre iratom ki.

A kérdésem az volna, van-e valami trükkje a Z80 busz-emulációhoz? Mármint időzítés szempontjából? A PIC PORTD-je lenne az adatbusz, egy másik port 4 bitje pedig a vezérlőjelek (CS, RD, WR és C/D). A vezérlőjeleket kapcsolhatom-e egyszerre? Write esetén melyik MCU kimenet legyen először érvényes? Az adatport, vagy a vezérlőport?
Olvasásnál értelemszerűen a PORTD bemenetnek lenne konfigurálva. A vezérlőjeleket itt is állíthatom-e egyszerre?
Title: Re: CoProcessor
Post by: lgb on 2014.October.22. 18:23:54
A következő tervem az, hogy a koprocit összekötöm egy PIC MCU-val, és úgy tesztelem, az eredményt (a koprociból olvasott byte-okat) pedig egy LCD kijelzőre iratom ki.

A kérdésem az volna, van-e valami trükkje a Z80 busz-emulációhoz? Mármint időzítés szempontjából? A PIC PORTD-je lenne az adatbusz, egy másik port 4 bitje pedig a vezérlőjelek (CS, RD, WR és C/D). A vezérlőjeleket kapcsolhatom-e egyszerre? Write esetén melyik MCU kimenet legyen először érvényes? Az adatport, vagy a vezérlőport?
Olvasásnál értelemszerűen a PORTD bemenetnek lenne konfigurálva. A vezérlőjeleket itt is állíthatom-e egyszerre?

Az az igazsag, hogy nem ismerem konkretan ennyire a Z80-at (se ... hehe), de azert az altalanos szokott lenni, hogy a konkret CS/RD/WR stb  jelet akkor illik aktiv allapotra hozni szerintem ha a mar a data/address stable, kulonben lehetnek meglepetesek, ha pont egyszerre tortenik. Nyilvan Z80 datasheet-et csak meg kene nezni, illetve tulkeppen jelen esetben az APU-et, hiszen most az a lenyeg, ha hozza akarsz fordulni.

http://www.hartetechnologies.com/manuals/AMD/AMD%209511%20FPU.pdf (http://www.hartetechnologies.com/manuals/AMD/AMD%209511%20FPU.pdf)

"Switching characteristic" resz pl. Pont utana meg szepen "grafikusan" ott vannak a jelszintek az ido fuggvenyben, hogy mikeppen is megy az iras es az olvasas.
Title: Re: CoProcessor
Post by: Ferro73 on 2014.October.23. 11:23:25
Lehet szimulálni de akkor magasabb órajellel kellene dolgoznia a PIC-nek.
CS RD WR C/D egy egy kimenetként használható.
De akkor már lehetne egy bemenetet is próbálni amit a CoPU küld amikor kész a számítás.
A PIC programjában esetleg tudok majd segíteni.
Milyen PIC típussal próbálkozol?
Title: Re: CoProcessor
Post by: Povi on 2014.October.23. 13:29:18
16f887
Miért kéne magasabb órajelen dolgoznia?
Ebben van belső oszcillátor, az 2MHz-en fut, és az OSCOUT lábról adnám az órajelet az APU-nak.
Egyébként úgy gondoltam, hogy először kiküldöm a PORTD-re az adat- / parancsbájtot, majd beállítom a C/D RD és WR lábakat, majd a legvégén tenném low-ra a CS-t. Addig úgy gondolom az APU számára tök mindegy, milyen jelek vannak neki bármelyik lábán, a CS aktív állapotában fogja öket feldolgozni. Itt jönne egy NOP, hogy legyen idő, majd a CS-t vissza high-ra.

Kb. hasonlóan menne, mint egy LCD kijelző meghajtása (annyi a különbség, hogy ott nincs külön RD és WR láb, hanem összevont R/W).
Title: Re: CoProcessor
Post by: Povi on 2014.October.23. 13:33:40
A PIC programjában esetleg tudok majd segíteni.
Eygébként a config bitek beállításával vagyok elakadva... :-) (tudom, gáz ügy :-))
Eddig 877-eseket használtam csak (a korábbi projektjeimben), most direkt vettem egy 887-est, mert annak van belső osszcillátora, és minél inkább egyszerűsíteni akartam az áramkört.
Title: Re: CoProcessor
Post by: Zozosoft on 2014.October.23. 13:51:46
Szerintem jól gondolod, én is igy csinálnám, és a Z80 is (fél-egy orájel eltolásokkal) elösször az adat és cimbusz beállit aztán a vezérlöjelek. Olvasásnál meg cim, vezérlés, és aztán nézi az adatbuszt.
Title: Re: CoProcessor
Post by: Ferro73 on 2014.October.23. 14:44:39
A 887-es egy 40 lábú ha jól olvasom 8MHz belső osc.
Nem ajánlom a belső osc ln is használtam de egy idő után rájöttem nem stabil.
Aztán használni kezdtem külső OSCilátort a 16 lábút tök stabil csak nagy helyet foglal.
Most olyan kristállyal próbálkozom aminek 3 lába van a középsőt földre a két szélső lábát
pedig az OSC1 és OSC2 lábra kell kötni.
Még egy dolog lehetne akkor a PIC röl adni a CLK-t a CoPU.
Title: Re: CoProcessor
Post by: Ferro73 on 2014.October.23. 15:02:34
16f887
Miért kéne magasabb órajelen dolgoznia?
Ebben van belső oszcillátor, az 2MHz-en fut, és az OSCOUT lábról adnám az órajelet az APU-nak.
Azért kellene mert így 2MHz belsővel sokáig tart az aktívitás ez nem annyira baj legalább nem kell az a NOP.
Ha 2MHz a CoPU akkor a 8MHz 1:4 oszthatod így jobb és kompatibilisebb lesz az EP-vel.
Title: Re: CoProcessor
Post by: Zozosoft on 2014.November.28. 12:10:42
Össze van még rakva a cucc? Majd akkor vinném a TTL szondát, és ránézhetnénk.
Title: Re: CoProcessor
Post by: Povi on 2014.November.28. 12:27:45
jó ötlet, hozzd :-)
Title: Re: CoProcessor
Post by: Zozosoft on 2017.February.13. 15:30:13
Belebotlottam az Ebay-en egy ilyenbe, gyorsan lecsaptam rá :-)
Mivel ez valami működő cucc része volt egykor, így remélem működő APU van benne, nem kínai hamisítvány :oops:
[attach=1]

Sajnos EPROM nincs a panelen, így nem lehet kideríteni, hogy mi volt a funkciója. Van rajta PIO, DART, STI... valami kommunikációs berendezés lehetett, talán CRC-t vagy ECC-t számolt a koproci?

Update: közben kigoogliztam: ez egy Heckler und Koch gyártmányú CNC vezérlőközpont egyik panelje. Így már érthető hova kellett az a sok számolás. A kommunikációs rész meg az érzékelők beolvasásához, motorok vezérléséhez.
Title: Re: CoProcessor
Post by: Povi on 2017.February.13. 21:59:47
de jó!!!!

már csak egy működő kártya kéne belőle, de Zozo, neked az 20 perc :-D

kiváncsi leszek az eredményre!!!
Title: Re: CoProcessor
Post by: Povi on 2019.September.08. 22:12:31
Csak hogy itt is meglegyen.
Előkerült egy eredeti koproci kártya!!!
Title: Re: CoProcessor
Post by: Povi on 2019.September.09. 19:51:25
gyors próba PC-táppal:

a 81-es (status) portot olvasva mindig 1-et kapok

a 80-as (adat) portot olvasva mindig ismétlődő 16 számot kapok (16 byte méretű a verem az FPU-ban)

ha lekapcsolom a tápot a koproci kártyáról, akkor mindig 255-öt olvasok, akár a 80-as, akár a 81 portról

tehát valamit csinál a kártya, de még nem azt, amit kéne neki

az FPU eléggé melegszik

ha az adatportra küldök egy bájtot, akkor utána olvasással ugyanazt kéne visszakapnom, ez nem megy

lehet, h ráférne egy élcsatlakozó tisztítás a kártyára???
Title: Re: CoProcessor
Post by: Ferro73 on 2019.September.09. 21:14:40
Esetleg az élcsatlakozó két oldala nem rövid záras?
Forrasztó ón,cin nem folyt át a lyukon?
Title: Re: CoProcessor
Post by: Zozosoft on 2019.September.09. 21:21:45
lehet, h ráférne egy élcsatlakozó tisztítás a kártyára???
Igen, elég oxidáltnak tűnik.
Title: Re: CoProcessor
Post by: Povi on 2019.September.09. 21:44:16
élcsatlakozó radírozás után is ugyanez a helyzet
Title: Re: CoProcessor
Post by: Povi on 2019.September.09. 21:59:19
Esetleg az élcsatlakozó két oldala nem rövid záras?
Forrasztó ón,cin nem folyt át a lyukon?
háát, elvileg amikor elrakták, akkor még működött... szóval ilyen szempontból jónak kéne lennie
Title: Re: CoProcessor
Post by: gflorez on 2019.September.10. 09:42:36
Vannak olyan modern skálázók is, amelyek + 12v-t + 5v-ból vagy + 9v-ből hozhatnak létre, mint amilyent az MSX slotban használtam.
Title: Re: CoProcessor
Post by: Povi on 2019.September.10. 09:45:20
Vannak olyan modern skálázók is, amelyek + 12v-t + 5v-ból vagy + 9v-ből hozhatnak létre, mint amilyent az MSX slotban használtam.
Thanks, yes, I know about it, I also have one, but for the quick test it was easier to use an old AT power unit
Title: Re: CoProcessor
Post by: Povi on 2019.September.10. 09:47:36
Egyébként lgb nyugtatgat, hogy biztos nem ment tönkre az APU, mert ha tényleg 16 byte-os a verme, és olvasással ciklikusan ugyanazt a 16 byte-ot olvasom, akkor gyanús, h valamennyire mégis működik. :-)

Engem kicsit aggaszt a melegedése, bár az adatlapján azt írják a max power dissipation-ra, hogy 2W (ami nyilván nem a tipikus, hanem a maximum maximuma, amitől még nem megy tönkre)
Title: Re: CoProcessor
Post by: Zozosoft on 2019.September.10. 09:51:55
élcsatlakozó radírozás után is ugyanez a helyzet
Cillit volt már? Tudod ami a 20 forintost is kifényesíti a reklámban :-)
Egyébként komolyan, az egyik legfontosabb felszerelés egy számítógép szervizben!
Title: Re: CoProcessor
Post by: Povi on 2019.September.10. 09:56:28
Cillit volt már? Tudod ami a 20 forintost is kifényesíti a reklámban :-)
Egyébként komolyan, az egyik legfontosabb felszerelés egy számítógép szervizben!
csak radír
sokkal fényesebb nem lett, de azért surlófényben látszik, h történt valami :-)
tényleg okozhat ilyen jellegű hibát a rossz érintezés?
Title: Re: CoProcessor
Post by: Zozosoft on 2019.September.10. 10:06:53
Okozhat. Arról se vagyok meggyőződve, hogy azok a tüskék elég jól érintkeznek. Nincs egy élcsatlakozó darabod, amit a tüskékre forraszthatnál?
Vagy esetleg a tüskéket egy picit összeszorítani satuval, hogy szorosabbak legyenek.

A eset leírás alapján a WR jelnek kéne utána nézni, hogy eljut-e az APU-ig.
Title: Re: CoProcessor
Post by: Povi on 2019.September.10. 13:06:51
mondjuk az érdekes, h a status regiszterből miért mindig 1-et olvasok
reset-kor elvileg nullázódnia kéne

az 1-es azt jelenti, h az előző művelet eredményeként lett carry
Title: Re: CoProcessor
Post by: Zozosoft on 2019.September.10. 13:09:15
mondjuk az érdekes, h a status regiszterből miért mindig 1-et olvasok
reset-kor elvileg nullázódnia kéne
A veremből olvasott bájtoknál hogyan áll a 0. bit? Ha ott is mindig 1, akkor lehet gyanakodni, hogy a D0 vonalon van valami baj.
Title: Re: CoProcessor
Post by: Povi on 2019.September.10. 13:10:46
A veremből olvasott bájtoknál hogyan áll a 0. bit? Ha ott is mindig 1, akkor lehet gyanakodni, hogy a D0 vonalon van valami baj.
mintha tényleg minden olvasott bájt páratlan lett volna, de erre most nem esküszöm meg...
este újra nézem
Title: Re: CoProcessor
Post by: Povi on 2019.September.10. 13:30:38
Vagy esetleg a tüskéket egy picit összeszorítani satuval, hogy szorosabbak legyenek.
A tüskék szerintem elég szorosak. Előbb-utóbb majd rá is kéne forrasztani őket (de nem 90°-ban hajlítottat), de egyelőre nem akartam maradandó változást a kártyán.
Title: Re: CoProcessor
Post by: Zozosoft on 2019.September.10. 15:43:05
Esetleg próbáld meg, hogy a 74LS245-öt kiveszed és annak a lábait is megcsiszolod. Azon át mennek az adatvonalak.