OldComp.cz

EDIT: odděleno z vlákna k příkazu $

A vobec, preco esxDOS stale nepodporuje lubovolne vyrazy na mieste argumentov ? By potom tento prikaz vobec nebolo treba...

to ale furt mluvite jen o zakladu Divide ramky 32kB. Pokud to bude neustale brzdene kvuli Divide standartu, tak to pujde hooodne pomalu a nebo to vyvojari zabali. Pritom uz je Divmmc daleko rozsirenejsi a obsahuje minimalne 128kB ramky nebo plnych 512kB ram. Proc tam ta pamet byla asi pridana?

_________________
http://velesoft.speccy.cz/

A pritom volanie vyhodnotenia vyrazu do romky zaberie menej miesta nez vlastna vyhodnocovancia rutinka + dalsi specalny bodkovy prikaz len kvoli tomu
Resp. neviem ako narocna by bola cela ta rezia okolo v esxDOS-e, ale mam pocit ze by to mohlo usetrit miesto v kode. Ale konecne slovo v tomto ma samozrejme sam Lordcoxis.

lordcoxis by si dal rict, ale mam silny dojem, ze ub880d na tohle neslysi...

Mne se libi, jak Miguel rika, ze NMI neni jeho zajem, to si resi ub880d.
Kdyby si tak nechal jen FAT, LFN a virtualni DOSy
a u BASICove syntaxe rikal, ze to je vec Busyho Chybi nam v basicu: cokoliv s DATA, SAVE OVER, seznamy souboru do promenne, sekvencni pristup...

_________________
// na co myslím, když sedím u oldkompů: Durov

Staci vyhodit podporu FAT16, pre ktoru uz nevidim dovod. FAT32 sa da pouzit aj na velmi malych SD kartach.
A optimalizovať kód, lebo subrutiny ako táto

sa opakujú v kóde nespočetne veľa krát. Za to by nás profesorka z priemyslovky na hodinách Mikroprocesorovej techniky po*****ala, čo by vzhľadom na jej prírodou dané parametre mohlo byť chápané ako odmena a nie trest.
m1

optimalizace je pekna vec ale tim se vzdy jen setri trochu mista. Odstraneni FAT16 by bylo fajn, ale stale to nikdy nebude stacit pro klasicke divide. Vemte si ze divide ma 32kB ram a ani nema kam zazalohovat videoram pred skokem do NMI. Takze se to resi pri kazdem stisku NMI ulozenim videoram 7kB na disk, kterej se tak neustale prepisuje na stejnem miste (prepsani stejneho souboru). Tak schvalne, kolikrat jde u dnesnich CF karet prepsat stejny sektor, nez zacne dochazet k degradaci? 7kB na videoram uz se neusetri, na to je davno pozde. Resenim je vetsi ramka, tedy Divmmc.

_________________
http://velesoft.speccy.cz/

Toz jsem Vase komentare mirne zneuzil k nemirnemu natlaku na autora esxDOSu,
dostal nejake cerstve informace a ... zmenil jsem skepticky nazor, myslim, ze se muzete na neco tesit uz na nejblizsim Foreveru!

ub880d, busy, baze, velesoft, martin1, lanex
mel byste na jare byt na miste

mozna uz jsem to psal nebo zapomnel napsat... esxDOS 0.9 opousti limit 32K, ma novou, poradnou spravu pameti

_________________
// na co myslím, když sedím u oldkompů: Durov

Toto som ja Zilogovi vzdy hovoril - 32kB je zalostne malo ! Ale Zilog si tvrdo zastaval nazor, ze interface nesmie mat viac ramky nez samotne ZX Spektrum...

Jelikoz Ziloga hajim v mnoha vecech, tak nejsem nestranny, on ma velmi casto pravdu.

A Miguel asi nerekl, ze opusti 32K, jen to, ze tak mrnava RAM nejde podporovat bez poradne spravy pameti.

Cekam, ze se k tomu nejak vyjadri ub880d.
Koluje takovy "vtip", ze kdyby Miguel opustil podporu 32KB divRAM, tak jej Dusky zabije.
Mirnejsi varianta je, ze kdyby Miguel opustil podporu 32KB divRAM, tak to Dusky neprezije.

_________________
// na co myslím, když sedím u oldkompů: Durov

ohledne te spravy pameti bych jen dodal:
- existuje uz nova verze firmware cpld pro divmmc interface a vyuziva uz pamet svym zpusobem. Ale navazat to na MMU by se dalo bez problemu.
- nejvice rozsirene divmmc verze maji bohuzel jen 128kB ram a pritom pak dochazi k chybam v zrcadleni stranek a ignorovani writeprotectu mapram rezimu. Take detekce velikosti ram musi byt psana opatrne, protoze je u 128kB verze jak rikam chyba a hrozi prepsani kodu samotneho systemu.

_________________
http://velesoft.speccy.cz/

Ještě si dovolím pár čerstvých poznámek od Lordcoxise předat,
v reakci na Martinův článek na https://sites.google.com/site/lost8bits ... xdos-disas
jako vysvětlení, proč je esxDOS takový, jaký je.

Různé části byly psány různými lidmi. Velesoft, ub880d, Mr.Spiv ...
Ty horší části jdou za mnou, pocházejí z prvních betaverzí, r. 2004-5.
Většinou nikdy pak už nebyly optimalizovány.
Některé byly napsány se záměrem "reentrancy" a tak nemohou být optimalizovány, jak by se zdálo...
Jiné optimalizovány byly, většina si to však nezasloužila, protože by nevyřešily důležitější problém.
Řešením je kompletní přepsání, na čemž teď pracuji.
Některý kód musí být stejně dlouhý pro divide i pro divmmc (viz NOPy u sys-fajlu pro divmmc).
Novou verzi už mám v gitu, zveřejním ji až dořeším specs/API.

_________________
// na co myslím, když sedím u oldkompů: Durov

A co takhle DivIDE kompatibilním způsobem rozšířit? DivMMC nechci, rád bych zachoval to IDE.

Je už opravená ta chyba, že se nedá příkazem RETURN vrátit z TRDOSového příkazového řádku? Myslím, že kromě toho mi na dosavadní verzi ani nic nechybí. Vlastně ani LFN. Nic proti, ale bude to nejspíš na úkor rychlosti, protože větší data... takže nevím, jestli to chápat jako skutečné zlepšení.

_________________
https://cygnus.speccy.cz ZX Spectrum 128k, Betadisk, DivIDE, ESXDOS

Jsem v kontaktu s Miguelem. Zatim to vypada dobre. Psal o novem esxdosu, ktery bude plne modularni a take bude vyuzivat plnou pamet DIVIDE i DIVMMC. Cim vic pameti, tim vice ovladacu, rozsireni, cache, RAM disk, vyssi rychlost, atd. Resim s nim ted moznost bootovani systemu z SD karty, aby se nemusela flashovat EEPROM. Na original DIVIDE by se musela s kazdou verzi esxdosu preflashovat eeprom, takze zadny boot systemu nehrozi. Na jakemkoli DIVMMC by se teoreticky dal do eeprom flashout bootovaci kod, ktery by tam jednou pro vzdy zustal a komplet esxdos by se natahl z SD karty bez dalsiho flashovani.

_________________
http://velesoft.speccy.cz/

Pri spravnom navrhu si myslim, ze by 32kB malo byt dost. Vo Flashke by mali byt sprava SD a FS, zaklad pre inicializaciu DIVxxx a podporu BASICu, API rozchodnik.
V RAM0 miesto pre SD/FAT buffre, systemove premenne a dalsie zakladne rutiny, co sa nevojdu do Flash. RAM1 a 2 pre dynamicke kniznice naplnane podla potreby, RAM3 scratchpad.
Je zbytocne drzat v RAM obsah, ktory nie je vacsinu casu pouzivany a da sa tam dohrat za menej ako 1/10 sekundy podla potreby.
m1

Obdivujem toto nadšenie, že už po troch rokoch vyjde nová vývojová verzia pre cieľovú skupinu ľudí univerzity tretieho veku.