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
![Smiley :)](/Smileys/phpbb/smiley.gif)
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
![Smiley :)](/Smileys/phpbb/smiley.gif)
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
![Smiley :)](/Smileys/phpbb/smiley.gif)
[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
![Smiley :)](/Smileys/phpbb/smiley.gif)
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
![Wink ;)](/Smileys/phpbb/ds_icon_wink.gif)
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
![Smiley :)](/Smileys/phpbb/smiley.gif)
A Pascal altal hasznalt APU parancsokat koszi, ez meg hasznos lehet!