OldComp.cz

Má TESLA ROM nějaký mechanismus, jak nahrát více binárních bloků paměti (tzn. např. 1500 bajtů od 0x1000 + 2000 bajtů od 0x8000 + ...) - jako to má ViLi ROM? Nebo je nutné to nahrát jako jeden spojený "blob" s rutinou, která to po spuštění příslušně rozhází po paměti?

Připadně mě napadá udělat něco jako spectrácký zavaděč (akorát ne v BASICu), který bude volat příslušné služby MIKOSu a jednotlivé bloky si načte z dalších souborů - ale to mi přijde už dost komplikované, to už snad radši ta "rozhazovací" rutina...

_________________
Zdraví
joker

Co vím tak neumí, MIKOS uloží blok do paměti tam, jak byl uveden rozsah při příkazu save. Nic víc. Ale jak píšeš pomocí malého loaderu to pomocí služeb mikosu snadno implementuješ.

_________________
https://github.com/72ka

Jen si nejsem jist, zda každý blok v hlavičce nemá adresu, na kterou se má uložit, tím by to ovlivnit šlo.

Ano, má, ale z toho co víme, tak nejspíš platí, že 1 binární soubor = 1 blok. Mně šlo o to, jestli v jednom souboru může těch bloků být více (jako v souboru typu .KÓD pro ViLi ROM), a to asi v Mikosu nelze.

Ale ono je to vlastně stejně jedno, vzhledem k tomu, že Tesla ROM prakticky nikdo nepoužívá (spolu se dvěma lidmi, co se mi na otázku o smyslu úpravy SW pro ni ozvali, jsme tohoto názoru 3 ze 3 ), pro ni nic upravovat nebudu a tohle téma je tedy passé.

_________________
Zdraví
joker

Teď tomu nějak nerozumím, zdá se mi to jako blbost.

To podle mne neplatí.
Soubor v MIKOSu se skládá z krátkých bloků za sebou jdoucích, každý má svou hlavičku s jménem souboru, svým pořadovým číslem atd.
Bloky jsou kratší než ve ViLi ROM.


Opět za mne blbost.
MIKOS to tak má přeci normálně.

Nedělené soubory, v jednom bloku, měla ROM s MikroBasicem.

Jak tedy v MIKOSu těch víc paměťových bloků do jednoho souboru uložím? Nejde mi o kazetové bloky, to si MIKOS dělí sám, jde mi o paměťové bloky. Příkaz K_S umožní zadat pouze 1 rozsah paměti k uložení, stejně jako vyvolání služby 0x160. A soubor se hned uzavře, nelze tedy udělat několik K_S za sebou a až pak uzavřít K_C.

_________________
Zdraví
joker

Jestli se nepletu tak MIKOS ukládá po sektorech kdy v prvním sektoru je jméno souboru. Následující sektory jsou data kdy v každý sektor má pořadové číslo a číslo souboru. Takže data jsou jeden celistvý blok, při chybě čtení se jde vrátit a provést nový pokus čtení …

Formát dat pro SAPI-1 je ZDE, pro ONDRU s TESLA ROM by měl být rozdíl akorát ve velikosti sektoru kdy SAPI-1 má 256byte a ONDRA 1024byte.

Takže pokud chceš více datových bloků tak je potřeba uložit/vyčíst každý do vlastního souboru zvlášť … nebo pokud to jde tak uložit jako jeden blok.

Jediná cesta jak uložit/načíst libovolné úseky je použít INTELHEX aneb ten má pro každý řádek počáteční adresu pro daný řádek. Na SAPI-1 je to možné ale jak je to s ONDROU a TESLA ROM tak to netuším. Taky umožňuje automatický start …

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

http://www.sapi.cz/

V dokumentaci Ondry se vůbec o sektorech nepíše, jsou tam uvedeny jednak "bloky" (bez bližšího upřesnění - já jim říkám kazetové bloky), po kterých probíhá čtení/zápis z kazety, a ty jakoby "obalují" to, co je tam uvedeno jako "funkční blok" - ten má vždy 256 bajtů. První bajt funkčního bloku určije jeho typ (":"/0x01/0x04/"A"/"B"), zbývajících 255 bajtů jsou data, jejich se význam se liší podle typu bloku.

Kazetový blok má celkem 275 bajtů, na začátku několik synchronizačních znaků 0x10 (3B, viz níže), pak následuje funkční blok (256B), pak název souboru (11B), číslo bloku v souboru (1B), pořadové číslo souboru (1B), kontrolní součet (1B) a pak zase 2 synchronizační znaky 0x10 (2B).

Ty synchronizační znaky 0x10 na začátku bloku mají být jak podle dokumentace k Ondrovi, tak podle https://www.sapi.cz/sapi/doku2/kpv.php#mikos dva, ale ve skutečnosti se ukládají tři. A ono to odpovídá i tomu, co je ve zdrojáku https://www.sapi.cz/sapi/data/mi40f_asm.php (btw. luštit to v mnemonice i8080 pro mě bylo utrpení ) - takže nejspíš i na SAPI se navzdory dokumentaci ukládají 3:



Pak taky na konci mají být synchronizační znaky 0x10, 0x00, ale je tam dvakrát 0x10 - což zřejmě nevadí, vypadá to, že čtecí rutina skončí na kontrole kontrolního součtu a dál je jí to jedno.


INTELHEX vypadá že Ondra neumí - příslušné příkazy (R/W/E) nic nedělají.
Automatický start je možný na Ondrovi při nahrání přes zkrácený příkaz "L" (místo "K_L"), pokud načtený paměťový blok začíná absolutním nepodmíněným skokem (0xC3), pak se automaticky po načtení provede. Jinak (po K_L) je nutné jej spustit ručně J, B, nebo Gxxxx.

Jo a díky za skvělou sbírku dokumentace (i všeho ostatního) ohledně SAPI.

_________________
Zdraví
joker

MIKOS ty bloky umí načítat i napřeskáčku, proto tak nějak čekám, že každý ten blok obsahuje i adresu, kam se má nahrát.
Systémovým způsobem to ovlivnit nepůjde, ale podvrhnout v blocích vlastní adresu (napsat si "saver" na ukládání segmentů paměti do jednoho bloku) by mohlo jít. A na nahrávání by pak nemusel být potřeba speciální loader, měl by fungovat ten systémový.
Ale ještě jsem se nedíval do disassemblingu.

Na toto existuju online konvertory. Ja som si napr. takto do Z80 mnemoniky prehodil vypis romky PP01 aby som sa v tom lahsie orientoval.

Ač by to tak dle dokumentace mohlo vypadat (a myslel jsem, že to tak je), ve skutečnosti pouze první kaz. blok typu "B" - binární (čili druhý v daném souboru, úplně první je typu "název" - 0x01) obsahuje rozsah pamětí, kam se nahrává. Ty další už rovnou obsahují pokračování dat. Takže to nelze.
Ještě jsem ale nezkoušel, co by se stalo, kdybych mu podhodil místo posledního "uzavíracího" bloku typu 0x04 další 2 bloky typu "B" - jeden se "zbytkem" dat prvního bloku (který by normálně byl v tom uzavíracím) a pak další typu "B" s novým rozsahem adres a dalšími daty.
Když zkusím nahrát bloky napřeskáčku, tak mi to hází chybu - chce je přísně sekvenčně.

Jo a ještě pár (možná zajímavých) zjištění - zjištěno na Ondrovi, na SAPI je to třeba jinak:
- adresy pro nahrání jsou uvedeny v opačném pořadí, než by odpovídalo logice i dokumentaci - nejdřív koncová adresa (k.a.), pak počáteční adresa (p.a.)
- tyto adresy jsou uvedeny v lomených závorkách < k.a. p.a. >, ale kontrolní součet adres se počítá bez otevírací, ovšem včetně uzavírací závorky!
- kontrolní součet celého kazetového bloku se má dle dokumentace počítat vč. pilotního rámce (počátečních bajtů 0x10), ve skutečnosti se počítá až od bajtu typu souboru
- kontrolní součty jsou dle dokumentace negovaným součtem příslušných bajtů, ve skutečnosti je to prostý součet

_________________
Zdraví
joker

Zdá se, že tedy jsem si to pamatoval blbě - MIKOS musí nahrávat sektory (bloky) souboru postupně, ne napřezkáčku, a blok samotný neobsahuje adresu, kam se má nahrát, jen své pořadové číslo (ze kterého se adresa počítat nemusí, protože se zřejmě nahrává čistě sekvenčně - opravdu jsem si to ale pamatoval jinak, protože jsme ve hře Hammurabi měli vadný blok, ale zbytek programu se dařilo nahrát, tento nekompletní program vylistovat a zjistit, o co mělo asi jít).
Tož se omlouvám za svou paměť, tudy cesta opravdu nepovede.