OldComp.cz http://oldcomp.cz/ |
|
Chyby ROM/BASICu http://oldcomp.cz/viewtopic.php?f=65&t=4947 |
Stránka 1 z 1 |
Autor: | Antony/DTA [ 22.01.2017, 18:50 ] |
Předmět příspěvku: | Chyby ROM/BASICu |
Aby sme ten SAM BASIC len nechválili, tak tu mám jeden príklad, ktorý ukáže hneď dve chyby: Nepresná nula a taktiež mal cyklus prebehnúť ešte raz pre a=0.5 . Příloha: simc0001.png [ 2.87 KiB | Zobrazeno 7449 krát ] |
Autor: | SCjoe [ 23.01.2017, 10:12 ] |
Předmět příspěvku: | Re: Chyby ROM/BASICu |
SAM BASIC bohužel vykročil ve šlépějích spectráckého, taky nebyl při uvedení produktu na trh dokončen... Chyb je více, např. http://www.worldofsam.org/node/69 Moje zkušenosti: - systém nezpracuje velký počet (stovku?) LABELů - obarvované instrukce či názvy procedur (CTRL+I, CTRL+P) občas způsobí různá chybová hlášení Chyby u basicového kalkulátoru jsou na pováženou, vždyť se autor prý poučil z chyb spectrácké romky a matematické rutiny jej živily nejen na škole ale také ve firmách (psal grafické a 3D knihovny pro nové herní konzole - PS a spol.) |
Autor: | Busy [ 24.01.2017, 13:53 ] |
Předmět příspěvku: | Re: Chyby ROM/BASICu |
Ked chcete mat exaktne presne vysledky, nepouzivajte floating-point format cisel. Floating point vzhladom na svoje kodovanie z principu nevie presne ulozit hodnoty ine ako 2^N (N je cele cislo) a ich sucty. Napriklad hodnota 0.1 predstavuje v dvojkovej sustave nekonecny "dvojtinny" rozvoj, pretoze sa neda vyjadrit suctom konecneho poctu celociselnych mocnin dvojky a tym padom sa ani neda zakodovat exaktne presne. A ked sa pocita s viacerymi nepresnymi hodnotami (napr. 0.1 + 0.1) tak nepresnost narasta. Ak chcete aby vam aritmeticke rutinky vysledky automaticky zaokruhlovali na (v desiatkovej sustave) najblizsie rozumne cisla, potom sa mozete lahko dozit ineho druhy chyby - napr. vysledok operacie 1.00000001 - 1.00000001 sa zaokruhli na najblizsie "rozumne" cislo, a tym je nula. Pokial pozadujete desatinne cisla s exaktnou presnostou, treba pouzivat fixed point aritmetiku. Kedze v beznych basicoch (napr. ZX) nieco take nemame, da sa to obist tak, ze vsetky hodnoty na vstupe vynasobime desiatimi (stomi...) tak aby sme nasledne pocitali len s celymi cislami, a na vystupe ich tou istou "bulharskou" konstantou zase vydelime. Presne takto pracuju aj rozne tabulkove programy (Excel...) pri nastaveni typu cisla na "currency" - tento format je urceny napr. na finacne vypocty, kde treba garantovat exaktnu presnost. |
Autor: | Antony/DTA [ 16.06.2018, 14:58 ] |
Předmět příspěvku: | Re: Chyby ROM/BASICu |
SCjoe píše: - systém nezpracuje velký počet (stovku?) LABELů No tak som zrovna na to narazil a LABEL-ov som mal tak do 30.Nepomohlo ani pridať pamäť pre basic, ale nevzdal som sa a tak som namiesto LABEL-ov vytvoril premenné (no oni sú to vlastne konštanty) a pred každý LABEL som dopísal REM a ide to. Pre úplnosť ešte dodám, že si s tým neporadí príkaz RENUM, ale to mi nevadí. |
Autor: | SCjoe [ 17.06.2018, 09:15 ] |
Předmět příspěvku: | Re: Chyby ROM/BASICu |
Antony/DTA píše: No tak som zrovna na to narazil a LABEL-ov som mal tak do 30. Je to různé. Asi záleží na celkovém obsazení paměti procedurama a využívání smyček s WHILE, DO, UNTIL, LOOP a taky na délkách pojmenování. Kód: 1 PRINT "Generator LABELu..." 2 FOR x=1 TO 111 3 PRINT at 1,0;x 4 KEYIN STR$ (x*2+100)+" LABEL l"+STR$ x+": PRINT "+STR$ x+": STOP" 5 KEYIN STR$ (x*2+101)+" REM xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" 6 NEXT x 7 CLS : STOP 8 REM ---------------------------------X Samík má jen část systémových proměnných definovanou třemi bajty (stránka,offset), zbytek si nese "zátěž" osmibitového systému do max. 65535 a vše důležité cpe do stacku, který vznikl na místě spectrácké obrazovky od 16384 do cca 19000, resp. s buffery až přes 20000. Lze získat více místa. Mám upravenu ROM s posunutým začátkem basicu, klidně až na 32000. Získá se tím např. dalších pár K pro prográmky, které se dosud cpaly do basicového stacku. Rozumné je jít ale jen na 27000, aby byly spustitelné i programy, které si ponechaly manýry ze Spectra a nastavují brzký konec basicu a start stroj. kódu kupř. od 30000. Další krok, posunutí basicových proměnných a bufferů výš přes původní počáteční adresu sam basicu (23755), se mi zatím úplně v ROM zmanipulovat nepovedlo a ještě je velký problém s programy, které nepoužívají systémový přístup s SVAR, ale natvrdo poukují. |
Stránka 1 z 1 | Všechny časy jsou v UTC + 1 hodina [ Letní čas ] |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |