OldComp.cz

ale podle pár příspěvků výše potřebuje sestupnou hranu, ale u klasiky to je klasický výběr(adresace) portu a k němu je signál RD nebo WR na jejichž hranu je třeba reagovat... takže minimálně něco co tyhle 2 sloučí jak pro zápis tak pro čtení



Tady je potřeba spíš myslet na FP aritmetiku než na celá čísla, ta Atmega zvládne z pohledu 8-bitu neskutečný kousky, ale nakrmit ji bude náročnější (různé typy čísel - mantisy, exponenty, znaménka, ofsety)

Já si to musím pořádně nakreslit a promyslet, nicméně už jen prostá změna na portech kompatibilitu odstřelí. Přijde mi že to bude brzdit ten režim, ve kterém se to FPU bude nacházet v 99.999% času. Musím si to dát pořádně dohromady...

Ale jistě, že by to umělo přesně i tu MH102, ale jen tu MH102, protože by jsi tam lezl jako jedinec s IQ 60 jen na horní a dolní bajt a nebyl by jsi schopen rozlišit nic jiného

Pokud tam budou ty oddělovací buffery, tak tam musí být ještě logika, která si musí pamatovat A0 a typ operace a taky jestli jsou plné.

_________________
Diagnóza: Touretteův syndrom, Koprolálie, Dyslexie, Obsedantně kompulzivní porucha.
Kalkulačky: Privileg PR56, TI51-III, TI57, TI58, TI59, TI83, TI-83 Premium CE, TI89
Počítadla: BOBO64, ZX48 plus, DG-88, Didaktik-M, C16, C64C, Amiga 500+, MZ800, MUPID C2A2

Taky bych se vybodl na slučitelnost s MH102 aneb jak se ukázalo tak její přinos je sporný, pokut by měla nějaký rozumný přínos tak by se asi i občas objevila osazená. Pokut bude plnohodnotné FPU tak půjde přímo nahradit programové řešení. Alternativně bude možnost aby FPU umělo i dvojitou či jinou přesnost samozřejmě vše v normovaném formátu.

Jen tak zběžně jsem nakoukl, jak to je řešeno to programové řešení a jak by se to asi překonávalo na FPU, nejsem nijak extra kovaný programátor, ale už i se sečítání či odečítání v plovoucí čárce by molo byt plichta pokut se vezme druhý operand z FACC v FPU.

Sečítání, odečítání, násobení a dělení má dva operandy a čtyři varianty kde se vezme první operand druhý operand je vždy v akumulátoru knihovny (FACC), porovnání má dva operandy a dvě možností kde se vezme druhy operand první operand je vždy v akumulátoru knihovny (FACC). Mocnina má také dva operandy kdy první je vždy v akumulátoru knihovny (FACC). Všechny goniometrické funkce mají jeden operand a to akumulátoru knihovny (FACC). Pak to je několik pomocných podprogramu na stěhování dat a převodní podprogramy z a na TXT formu. Rozumně nasraný program bude použit programovou knihovnu tak bude držet čísla v binárním tvaru, takže bude fajn pokut bude mít FPU vlastní akumulátor a pro „všechny“ operace mít dvě varianty a to že se operand z akumulátoru FACC bud bude nahrávat nebo se vezme akumulátoru v FPU čímž by se ušetřil nějaký ten přenos tam a zpět.

Nebilo by od věci kdyby si někdo dal práci a zkusil by aspoň teoreticky projit kolik a jak moc by ta FPU pomohla aneb jak moc by se dalo ušetřit stehováni dat … jedna věc je co umí knihovna a druhá jak jí daný program používá.

Pod knihovnou mám na mysli soubor podprogramu pro práci v plovoucí řadové čárce aneb ten co byl v dokumentaci k SAPI-1 a bodle všeho se bude nacházet i v BASICích v PMD-85, IQ151, ale i MBASICu pod CPM.

Pokut jede o to, jak bude připojená ta ATmega tak bych se radši klonil k tomu, aby měla dvě adresy jednu pro řízení a druhou pro data (obdobně jak to je třeba u 8251). Bez nějaké té spojové logiky to nepůjde aneb ta ATmega není určená jako inteligentní periferie k 8080/85, 8048, … , pokut je mi známo tak přímo jako periferní obvod jde připojit jen 8041/42 což by měla být odvozenina od 8048. Ono by to bez té spojové logiky šlo ale ta ATmega by musela běžet tak o řad rychleji aby to programově stihala. Pro ty spojové obvody by se hodil obvod 3212 ale jeho velikost je asi moc ale ušetřilo by to nějaké to IO v kombinačně sekvenční logice. V řadě TTL jsou obvody 74651 až 74653, které jsou přímo učené k propojení dvou sběrnic ale kde je sehnat, takže to skončí u těch již zmiňovaných budičů plus něco kombinačně sekvenčního.

_________________
Ne všichni jsme měli z češtiny za jedna, aneb jsem dyslektik a dysgrafik.

http://www.sapi.cz/

Tady je jedno z možných řešení pomoci obvodu 3212 aneb jak k sběrnici ARB-1 v SAPI-1 připojit 8035 co se stara o sít.

_________________
Ne všichni jsme měli z češtiny za jedna, aneb jsem dyslektik a dysgrafik.

http://www.sapi.cz/

U ATmegy lze používat vnitřní zásobník a paměťové registry k uchování proměnných. K tomu se mohou přidat makroprogramy v EEPROM a tak se dají snadno provádět komplexní složité výpočty jen jednoduchým příkazem.

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement

Vychází mi že u nejrychlejší operace, násobení bajt x bajt, bude výsledek k dispozici za 4 us, může se tedy hned číst bez čekání a nemělo by to být pomalejší než MH102. Jen bude potřeba navíc na začátku odeslání 1 commandu. Ale hlavní přínos se samozřejmě očekává spíš u složitějších operací.

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement

Myslím že by se hodilo mít už vcelku vyčerpávající souhrn funkcí co ta Atmega bude podporovat aby bylo jasné, kolik jich vlastně bude. Odhaduju to na cca 40 funkcí, AVX-512 z toho asi nebude . Pokud by se totiž vlezly do nějakého takového rozumného rozsahu, tak bych navrhnul je zduplikovat pro různou přesnost. Tedy že by programátor vůbec nemusel brát v úvahu nastavení FPU, ale jen by poslal správnou instrukci. Uvedu příklad 001 - násobení 8x8INT, 002 - násobení 16x16INT, 003 - násobení 32x32INT. 004 - násobení 8x8FLOAT 005 - násobení 16x16FLOAT atd. až do 6x40, tedy 240dec a zbylo by několik (15) speciálních kódů pro řízení Atmegy. Co byste tomu řekli? Na základě toho by nám stačil jen jeden bajt/port co nastavuje násobičku a operaci. Ta by se už nastavila sama dynamicky v závislosti na kódu funkce a už by očekávala odpovídající čísla a taky by je vyplivla v odpovídajícím formátu. Samozřejmě si to můžu představovat jako Hurvínek válku tak jestli je to blbost, nebo je v plánu mít stovky funkcí, tak mě opravte .

Ad ta 3212 - raději bych se držel moderních součástek. Proč? Aby nebylo potřeba letovat separátní napájení, máme k dispozici příkon jen do 180mA co maximálně žere ta násobička + ztráty na kabelu a ta logika okolo 2 mA Atmegy už povážlivě nabobtnává . Tak doufám že existuje modernější funkční ekvivalent. Se separátním napájením samozřejmě tento problém odpadá ale musí se to přiletovat. Tohle čarování už je taky nad moje velmi skromné znalosti, já tak ještě nějak splichtit pcb podle schématu ale vytvořit a propočítat toto schéma jako takové, to ani omylem.

Jinak jsem rád že se to takhle rozjelo až se divím tomu zájmu . Ale mít konečně univerzálně osaditelné FPU je lákavé .

Na připojení ATmega a jinejch by bylo asi lepší SPI rozhraní.
74HCT299 se dá pořád koupit,tak jen k tomu přidat jednoduchou řídící logiku.
FPU si může taky pamatovat třeba 500GB programů ve flešce

_________________
Diagnóza: Touretteův syndrom, Koprolálie, Dyslexie, Obsedantně kompulzivní porucha.
Kalkulačky: Privileg PR56, TI51-III, TI57, TI58, TI59, TI83, TI-83 Premium CE, TI89
Počítadla: BOBO64, ZX48 plus, DG-88, Didaktik-M, C16, C64C, Amiga 500+, MZ800, MUPID C2A2

Ano s commandem je to takhle nějak podobně myšleno - pro integer čísla násobení a dělení v 8 signed a 8 unsigned formátech, pro float čísla import a export čísla v 16 formátech do zásobníku a pak asi 90 operací s číslem v zásobníku, plus pár commandů pro řízení programu v EEPROM.

Kvůli možnosti zacyklení uživatelského programu běžícího v EEPROM by asi měl být pin /RESET buď ovládaný hlavním procesorem nebo alespoň připojený na globální RESET, aby se dal program přerušit.

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement

tady si prosím prostuduj Pandův komentář co by to mohlo umět... u FLOAT se nemá cenu bavit 8/16, tam jsou to minimálně 4 bajty na číslo, případně více - ale je spíš třeba řešit v jakém formátu to číslo je (počet bitů mantisy, exponentu, kde je znaménko, jak je posunutý exponent) - sčítání, odčítání, násobení, dělení (včetně třeba celočísleného a zbytků), mocniny, odmocniny, abs, goniometrické funkce (sin, cos, tan, arcsin, arccos,arctan), logaritmy,

taky je potřeba promyslet jak říct ATmega že má pracovat s novou hodnotou nebo s vnitřním FP akumulátorem, případně kolik místa na FP čísla bude v ATmega (aby se nemusely přenášet pořád tam a zpět) - doporučl bych inspiraci třeba v SW kalkulátoru v romce ZX spectra

Suhlasim s l00k-om, naco zbytocne znovu vymyslat koleso ? Zasobnikova koncepcia vypoctov je uz davno vymyslena a v praxi osvedcena - pracuje takto spominany kalkulator v romke ZX Spektra, ale napriklad aj seria matematickych koprocesorov x87. A tiez vdaka zasobniku netreba neustale presuvat data medzi CPU a FPU.

Ona i Am9511 má jakousi malou cache pro 6 čísel. Sice je přístupná ne na přímo ale postupně z jedné strany ale taky určitě slouží ke stejné věci - úspoře přenosu dat. I ta i387 už má interní 1kB cache pro snížení objemu přenosů dat.

Pokud už něco existuje a je to praxí ošlehané řešení, tak sem s ním. Určitě není potřeba znovu vymýšlet kolo, i jen prostá implementace existujícího a návrh zapojení budou již dostatečně náročné na domácí podmínky a bude zajištěno že to bude správně fungovat .

Pozrel som na Am9511, je to sice uz hodne stary cip (nakoniec aj compy, do ktoreho ho chceme dat, nie su zrovna najmladsie), ale je to presne to co chceme. Takze pripojme Am9511 a nemusime nic riesit

Am9511připojit, to je poněkud náročný úkol. Zejména kvůli potřebě specifických podpůrných čipů, mezi nimi na prvním místě bezpodmínečně nutný i8238 coby správce sběrnice při použití i8080. S šedou myškou i8228 si toto FPU nepovídá... Zvedněte ruce kdo i8238 máte osazený, tedy mimo mého krutopřísně vytuněného PMD 85-3 .

Ale jinak by časově dobře odpovídal, není zase tak o mnoho mladší než i8080A, komunikuje po 8bitech a umí toho z matematiky skutečně hodně .

Jeho funkční emulace existuje přes ARM na Sharpu, Mikes21 to na začátku diskuse zmiňoval. Vyrobil též kartu s živým FPU, jejíž jedné kopie jsem též hrdým majitelem, co se dá k Sharpu taky připojit .