OldComp.cz
http://oldcomp.cz/

Chyby ROM/BASICu
http://oldcomp.cz/viewtopic.php?f=65&t=4947
Stránka 11

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
simc0001.png [ 2.87 KiB | Zobrazeno 4024 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 11 Všechny časy jsou v UTC + 1 hodina [ Letní čas ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/