Konference: Počítač SHARP MZ-800 a emulátory

Michale dulezite polozky jsou BLM a DSM. Od nich se odviji vse.

BLM rika kolik vet je v jednom alokacnim bloku. DSM zase rika jake cislo 
muzes pouzit a to zda je mensi nez 256 a tim padem se vejde do jednoho 
bajtu ci ne. To je dulezite, protoze podle toho bude adresar budto 16 
polozkovy nebo jen 8 polozkovy. Soucasne DSM musis vydelit 8 a uvidis 
kolik bajtu musis pripravit na alokacni bitovou mapu ALV0 - zde se 
nemuzes moc rozjet a nesetrit, protoze nemas moc volne pameti a vetsina 
cpm ma tento buffer pro jeden disk nekde okolo 48bajtu. Take az budes 
volit velikost BLM, tak je samozrejme lepsi mensi cislo at je alokacni 
blok mensi.

Proto vlastne BSH se vypocita z BLM a EXM se vypocita (zjisti) z 
velikosti DSM a BLM napr. dle tabulky co posilal Pavel.

Radek


Dne 2.2.2012 12:01, Michal Hučík (sharpemu tu byla ta zakroucena vec pandora.cz) napsal(a):
>
>
> Aha, dekuji za vysvetleni ... Tak nejak na pozadi uz mi to zacina
> dochazet, ale asi se tim jeste budu muset trochu prokousat :) Pokud to
> tedy chapu spravne, tak v zavislosti na BSH, BLM a EXM se m.j. urci i
> datovy typ pro sectors v polozce adresare. Tzn., ze pokud je cluster =
> 1kB, tak sectors je uint8_t, pri 2kB => uint16_t... ve chvili, kdy
> nastavim. napr, ze polozka adresare popisuje 32kB, a cluster = 8kB, tak
> do jedne polozky muzu nacpat 4 alokacni bloky a sectors bude tedy 32
> bitove cislo?
>
> Co jsem se dival napr. do NIPOSu, tak ten nastavuje u vsech disku max.
> pocet polozek adresare na 128, stejne tak to vidim i u cp/m 4.1, tak
> proto mne prekvapilo tvrzeni, ze by to melo byt jen 64...
>
> Michal
>
> Dne 2.2.2012 1:53, Radek Suk (sharpemu tu byla ta zakroucena vec pandora.cz) napsal(a):
>>
>>
>> Obecne muze byt vice polozek v adresari nez 64 ale neni bezne. Spise
>> by chtelo rozvinout diskusi na nejakem konktretnim pripade.
>>
>> Jinak existuje zavislost a to ta ze kdyz se kontroluje adresar coz se
>> dela u FDD ale nedela se to napr. u Ramdisku tak CKS=(DRM+1)/4. Proto
>> pri bezne diskete 720KB je DRM=127 a CKS=32.
>>
>> EXM rika jak velkou pamet popisuje jedna polozka adresare. Bezne se
>> popisuje 16KB ale pri vetsich ulozistich je to vice. Napr. pri kdyz je
>> zde cislo 3 tak to znamena (3+1)*16=64KB - a tak jeden zaznam v
>> adresari umi popsat 64KB dat.
>>
>> Co se tyce uint8_t dext - tak zde se vyuziva 5 bitu a tak povolene
>> cislo je 0..31. - Dalsi bity jsou ulozene v S2 a tam se vyuziva 4
>> bity. Jinak v CR se vyuziva 7 bitu - celkem kdyz to spocitas tak je to
>> 16 bitu a to je 2^16*128=8MB a to je max. soubor v cp/m v2.2.
>>
>> Az bude vice casu tak se chci podivat na to jak jaky system nastavuje
>> RD a FDD. Zatim jsem nasel jiste nedostatky a az si potvrdim ze to
>> spravne chapu tak bych to zde otevrel k diskusi.
>>
>> Radek
>>
>>
>> Dne 1.2.2012 13:46, Michal Hučík (sharpemu tu byla ta zakroucena vec pandora.cz) napsal(a):
>>>
>>>
>>> Ahoj,
>>>
>>> postupuji dale a zacinam tedy pracovat na cp/m filesystemu, ktery je jiz
>>> mnohem variabilnejsi a u ktereho bude zajimave vytvorit i drivery pro
>>> RD, RD image a pripadne i pro IDE - nicmene prozatim je funkcni jen IDE8
>>> v NIPOSu.
>>>
>>> Jako zdroj informaci o specifikacich formatu jsem pouzil predevsim tuto
>>> stranku http://www.sharpmz.org/succpminfo06.htm
>>>
>>> Popis adresarove polozky jsem asi nejak prehlednul, nebo tam neni,
>>> nicmene snad jsem jej poskladal dobre i po pameti.
>>>
>>> I pres popis jsem bohuzel nejak nepochopil vyznam polozek EXM a CKS.
>>> Taky mi vrta hlavou informace, kterou tady pred nedavnem napsal tusim
>>> Radek, ze v cp/m na logickem disku nemuze byt vice jak 64 souboru. Pokud
>>> vite, muzete mi prosim pomoci zodpovedet tyto 3 veci?
>>>
>>> Tady jsou struktury uz s mym komentarem:
>>>
>>> #define FS_CPM_LSECTOR_SIZE 128
>>>
>>> typedef struct {
>>> uint16_t SPT; // SPT - sectors per track
>>> uint8_t BSH; // BSH - block shift = pocet cp/m log. sectoru v jednom
>>> fyzickem
>>> uint8_t BLM; // BLM - block mask = pocet cp/m log. sectoru v clusteru
>>> - 1
>>> uint8_t EXM; // EXM - extent mask ???
>>> uint16_t DSM; // DSM - highest block number = max. pocet clusteru -
>>> systemove bloky - 1
>>> uint16_t DRM; // DRM - highest directory entry number = max. pocet
>>> polozek adresare - 1
>>> uint16_t ALD; // ALD - bitmapa prvnich 16 clusteru, 15. bit = 0.
>>> cluster, '1' = pouzito jako directory
>>> uint16_t CKS; // CKS - Directory checksum ???
>>> uint16_t OFS; // OFS - poc. systemovych stop na zacatku disku, ktere
>>> preskocime
>>> } FS_CPM_DPB;
>>>
>>>
>>> /*
>>> * - fname, ani fext neni ukonceno zadnym specialnim znakem
>>> * - nepouzite znaky musi byt vyplneny mezerou (0x20)
>>> * - 7. bit 0. bajtu extenze indikuje priznak R/O
>>> * - 7. bit 1. bajtu extenze indikuje priznak SYS
>>> */
>>> typedef struct {
>>> uint8_t user; // 0 - 15, 0xe5 = smazana polozka
>>> uint8_t fname[8];
>>> uint8_t fext[3];
>>> uint8_t dext; // cislo extenze (muze jich byt opravdu 256?)
>>> uint8_t unused[2];
>>> uint8_t sectors;
>>> uint16_t clusters[8];
>>> } FS_CPM_DITEM;
>>>
>>>
>>>
>>> ---
>>>
>>
>>
>> ---
>
>
> ---
>
>

Ostatní příspěvky vlákna:

cp/m filesystem (Michal Hučík, 1.2.2012 13:46)

Re: cp/m filesystem (Pavel Železo, 1.2.2012 18:13)
Re: cp/m filesystem (Pavel Železo, 1.2.2012 18:27)
Re: cp/m filesystem (Radek Suk, 2.2.2012 01:53)

Re: cp/m filesystem (Michal Hučík, 2.2.2012 12:01)

Re: cp/m filesystem (Radek Suk, 2.2.2012 13:08)