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

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

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.

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

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.

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

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?

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.

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)

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.