OldComp.cz

Protože Czech Human ještě doplnil poznámku ohledně přepínání módu rozlišení versus rychlost, tak toto musím hned utnout.

Ty jsi Honzo špatně pochopil tu poznámku o 38 bitové přesnosti. Tak to není. Rozlišení mantisy (zjednodušeně řečeno ekvivalent počtu platných číslic při exponenciálním vyjádření A.AAAAAA x 10^N) je 23 bitů. A protože LOG(2^23) = 6,92, tak je k dispozici necelých 7 dekadických řádů, tedy jedna cifra před desetinnou tečkou a max. 6 cifer za ní. Jak u PMD-85 tak u FPU. To číslo 38 uvedl 100k jako maximální možnou hodnotu řádu celého čísla FLOAT - tedy 10^38. Takže přesnost ve smyslu rozlišení je pořád stejná, nic se nepřepíná a ani nedá přepínat.

A taky bylo správně řečeno, že jediná cesta k využití potenciálu FPU v BASICu je změna všech konverzních procedur, které převádí dekadický zápis na FLOAT, degradaci na INT16, INT8 a prostě všude. A s tím se asi opravdu nikdo v dnešní době párat nebude. Zbývá jedině nativní assemblerovská zrak vytírající aplikace. Tam ten potenciál pro zásadní urychlení výpočtů je. Ale jen tam.

Aha, takže se jedná ne o přesnost, ale o rozsah čísla. No já nevím ale 2^38 nebo 2^32 či kolik, jaký je v tom na 8bitu s 48 kB RAM rozdíl? Kdo byť teoreticky bude na 2 MHz mašině počítat se stovkami kvadrilionů a ještě v plovoucí čárce na X míst? To je úplně zanedbatelná položka u čísla co má 20 míst, HW nepřesnost výpočtu bude mít větší dopad na výsledek než nějaký zbytek za desetinou tečkou.

Já to myslel tak, že místo natvrdo nadrátovat v Basicu všechny funkce na FPU je lepší mít dvě sady příkazů - pro CPU a pro FPU. FPU by se používalo běžně, ale pro mimořádně velká čísla by se dal programátorem vynutit CPU, když taková hypotetická aplikace bude vznikat. Podle mě taková situace nemá reálně šanci vzniknout, protože omezení rozsahu čísla je relativně mnohem menší problém než omezení rozsahu adresovatelné RAM na 64 kB, zobrazovacích možností a tak vůbec. Jak už jsem psal - jsem pouze snílek a uvědomuju si to, IQ 151 nemám a udělat ten modul ani SW neumím. Jen mi přišlo na mysl že když už je tu ta možnost přilepit toto zajímavé FPU k PMD, tak k čím více 8bitům se ještě přidá, tím je větší šance že pro ně někdo napíše něco užitečného. Toť vše.

A pokud to smyslu nemá, vzhůru do Assembleru, případně Pascalu MT+ (na ten se určitě podívám až budu mít FPU funkční). Určitě nebudu trvat na cestě, která nikam nevede. Ale zase to lze skoušet jen když ten HW je připojený k počítači .

Možná by tahle knihovna v C mohla pomoct s případnou implementací FPU pro emulátor i když je zaměřená na Z80 a 8085... https://github.com/z88dk/z88dk/tree/master/libsrc/_DEVELOPMENT/math/float/am9511 a nějaké povídání https://feilipu.me/2017/02/22/characterising-am9511a-1-apu/

Konečně mi došly všechny díly na FPU a Liborova konstrukce funguje i na mém začarovaném PMD, když se zadaří . Tím bych dostupnost tohoto FPU pro PMD bral jako oficiální .

Malá ukázka co FPU dovede s Basicem V3.0. Sice je to pomalé, protože Basic je tak jak to běží pomalý, ale běhá to - program nejdříve vykreslí sinusovku spočítanou přes FPU a vzápětí i CPU viz. video https://uloz.to/file/UVcR4OcS7fmQ/20220621-221246-mp4#!ZJWxAmR2ZJHmZGx3MwZkZwRmMQH1Z1SgMwqJZwWLMJjlqmH4LD==

Systém je relativně jednoduchý - Libor L.A. napsal 3 krátké prográmky ve strojáku (dostupné na minulé stránce), které fungují následovně: pro plnění FPU daty z Basicu je PUSH$. Dále se musí FPU zaslat příkaz co s daty má dělat, jakou funkci použít (je jich 43) na to je CMD$. A naposled opětovné vyčtení dat z FPU do Basicu POP$.

Problém je, že Basic dělá dost operací okolo a ten program je napsaný aby to fungovalo, ne aby to běželo rychle. Proto pokud by někdo byl ochotný se na něj podívat a zrychlit jeho běh v Basicu, budu dotyčnému velmi vděčný. Jediné aktuální omezení je to, že běžný řetězec v Basicu má délku 255 bajtů ale jistě by se to dalo přiohnout .

Nyní je 2 MHz CPU zhruba o 10% rychlejší než FPU při výpočtu sin(X). Pro představu jak moc to Basic brzdí stačí konstatovat, že reálně to FPU je 5x rychlejší než 38 MHz Z180 CPU. Prostoru ke zrychlení tu tedy je poměrně dost.



FPU se ovládá na portech:

3Ch = datový registr FPU pro přístup k jeho zásobníku
3Dh = command/status registr FPU
3Eh = při čtení se zde objeví skutečný výsledek čtecí operace, při zápisu fakticky nuluje sekvencer

Pokud chci přečíst data z datového registru FPU, musím provést sekvenci IN 3Ch - IN 3Eh.
Pokud chci přečíst data ze status registru FPU, musím provést sekvenci IN 3Dh - IN 3Eh.

Samotné čtení z registrů 3Ch a 3Dh pouze nastartuje proces ale nevrací výsledky!

Já bych osobně měl jeden námět na zrychlení. Realizace pomocí CODE je sice názorná, ale BASIC musí při volání vždy nalézt proměnnou (např. PUSH$), pak se její obsah musí někam zkopírovat, pak zavolat, atd. Rychlejší varianta bude přes funkci USR.


EDIT: Honzo, ta díra M3 vlevo nahoře na tišťáku FPU je pro podpěrný sloupek M3x11...

Ano, o sloupku vím ale neměl jsem ho po ruce a takhle se to lépe zacvakává do ROM portu - začínám u GND a VCC strany. Program tu je stačí doplnit / přepsat a uvidíme jak se to projeví.

Pozor, pro použití těch ASM rutin je třeba je relokovat do nějaké bezpečné oblasti. Samotný příkaz CODE díky tomu, že si to vždy před použitím znovu někam kopíruje, si to může dovolit kopírovat do místa editačního buferu. Takže USR by po prvním INPUTu měl utrum.

S tím sloupkem: on je jen podpěrný, při zasouvání by neměl vůbec překážet...

V tom případě by se asi daly využít hodnoty použité RAM a podle nich potom poskládat ty strojové prográmky do volného místa nad programem s proměnnými a před koncem řetězců. Program je malý a jde o jednu verzi PMD s dostatkem RAM, tak by asi neměl být velký problém.

Chtel jsem se zeptat, jak to mate s teplotou toho FPU? Me to na Sharpovi docela pekelne hreje, tak jsem tam dal jeste i maly ventilator.
Jinak s tim BASICem, ktery jsem upravil pro FPU, jsem se pokousel delat vsechno mozne, ale celkovy benefit byl tak 5-15%. IMHO pokud cely ten sw nebude v asembleru, tak bych vetsi zrychleni neocekaval.
Popripade, pokud existuje pro PMD nejaky kompilator, ktery by se mohl upravit pro pouzivani FPU, tak by to mohlo byt zajimavejsi.
Jen pro pripomenuti: http://oldcomp.cz/viewtopic.php?f=133&t=6241&hilit=amd9511+sharp, ale je to moc pekny kus hw

_________________
Sharp MZ-800++, MZ-1500++, MZ-2500++, SM-B-80T, MK-14_replica, HP-85, ZX-80+replica, ZX81, ZX-Spectrum+replica++, PMI-80+replica, SAM coupe++, PMD-85-2A+3, Didaktik-M, SORD-M5, TI-57, TI-59+PC-100, TI99/4A, ZetaV2+ppp, ZX-uno, Petr

Originál AMD docela peče, přeci jen má skoro 2W tepelný výkon, to je cca jako 286ka. Ale zase nic kritického, dočetl jsem se že ty FPU pečou a je to jejich normální vlastnost. Dá se na něm udržet ruka, takže to má méně než 60°C, když si vzpomenu můžu to zkusit oměřit. S PMD to FPU navíc nedělá spíš nic než že by něco dělalo a má malou frekvenci, to chlazení pomáhá . Osobně to hodlám následně řešit nějakým malým pasivem aby se teplota udržela do 60°C i v horším proudění vzduchu v krabičce a víc to nebudu řešit. Mám ještě Intelovu verzi i8238 a ta se tedy zahřívá výrazně méně, evidentně lepší výrobní proces.

Pro PMD existuje Pascal MT+, který toto FPU má přímo podporovat přes knihovu tak si ho v dohledné době vyzkouším kolik pravdy na té podpoře je. Tam by už měl být ten rozdíl mezi FPU a CPU o poznání větší ve prospěch FPU.

Destičku mám taky, je to ostatně jediný díl na Sharp co vlastním

Dorazily mi pcb, tak jsem to sletoval a vyzkoušel. Výsledek - funguje to takže už není problém mít ROM modul a FPU naráz . Drobná vada designu mě nemohla zastavit - to je tak když si v Kicadu napasujete na pouzdro DIL 14 patici DIL 16 . No ale tak je to prototyp za 0,5 $ tak se to snese a pár drátků vše napravilo...

To horní pcb je univerzální a lze na něj připojit i FRB konektor, takže ho lze do slotu pro ROM modul v PMD připojit stejně jako Liborovu verzi bez nutnosti vlastnit 4 MB ROM modul.

Tím pádem je možné mít koprocesor s Basicem, což řeší poměrně nepříjemný problém "jak dostat do PMD Basic když konektor pro ROM modul je obsazený" což se buď dá "řešit" poněkud riskantní výměnou dílů za chodu a modlit se že PMD nezamrzne, nebo takhle. Stejně tak tato kombinace otevírá i pohodlné načtení programů do PMD vzhledem ke kapacitě modulu až 4 MB a zavaděče do RAM (je to modul od Libora L.A. jen s vyvedenou sběrnicí). A lze samozřejmě přidat cokoliv dalšího, protože FPU je na precizní liště a dá se sundat.

Hned jak bude více času, připravil bych novou verzi "podpory" FPU pro BASIC. Přeci jen se na základě té "nulté" verze s příkazem CODE nasbíraly nějaké podněty. Teď jen návrh vnější podoby volací funkce:

STATUS=USR('D030,LVAR[,CMD[,RVAR1[,RVAR2]]])

kde:

STATUS je proměnná BASICu, kam se předá stavové slovo FPU po ukončení výpočtu
'D030 (nebo jiná adresa v RAM) je adresa driveru FPU v paměti PMD-85
LVAR je povinná proměnná BASICu, kam se uloží výsledek
CMD je nepovinná hodnota požadované funkce FPU (podporovány budou jen funkce nad proměnnými FLOAT)
RVAR1/RVAR2 jsou nepovinné proměnné BASICu se vstupními parametry

- Pokud se neuvedou proměnné RVAR1 nebo RVAR2, nebudou prostě "nasunuty" do zásobníku v FPU, ovšem funkce se vykoná nad poslední položkou zásobníku (TOS) nebo nad posledními dvěma položkami (TOS+NOS), to podle zvolené funkce.
- Pokud v sekvenci STATUS=USR('D030,LVAR) nebude uvedena ani požadovaná funkce CMD, zvolí se nějaká default funkce, která se ukáže jako nejčastější volba.

Protože BASIC v PMD-85 je přinejmenším derivát MS BASICu 8k, uveřejním i zdrojové kódy pro případný přenos na jiné stroje.

Tolik prozatímní návrh.

Budu se těšit na výkonový vzestup i další případné platformy, kupříkladu SAPI. Není jen PMD . Mým dalším kandidátem je PP-01 ale to má ve svém Basicu čísla uložené v z pohledu float výpočtů nevhodném formátu.