OldComp.cz

To se mýlíš - koukni na zdroják MDOSu 2.0:



Vyzkoušejte naformátovat disketu na 80*10 a pracovat s ní pod MDOSem 2.x. Práce je cca 4 násobně pomalejší. Perfektně je to vidět na kopírovaní souborů v MFC, kdy v jednom okně je 80*09 a ve druhém 80*10


Projevuje se jen na MDOS 2.x !!!

A toto je také zajímavé. Vysvětlí mi někdo, proč se při read a writte commandu dává vždy GAP 10?

Prosím upresniť ako to mám chápať. Sú možnosti:
1. disketa formátovaná MDOS 1 a čítaná s MDOS 2.x
2. disketa formátovaná MDOS 2.x a čítaná s MDOS 2.x
3. disketa formátovaná MDOS 2.x a čítaná s MDOS 1

V ktorej alebo ktorých z týchto možností sa to spomalenie prejavuje?

_________________
Oznamy o novom príspevku mi na mail chodia iba sporadicky, takže keď sa nehlásim v diskusii, tak je to tým. V 80% nepríde mail vôbec.

1 i 2 se bude zpomalení projevovat (a 1 bude dokonce ještě více brzdit díky chybě se špatným číslováním druhé strany)
3 zde nevím, MDOS1 jsem nikdy neměl, ale obecně s MDOSem 1 nejsou problémy co se řadiče týče. Ten čte všecko, rychle a dobře

Edit: Jo a je vysoce pravděpodobné, že to je podobně jako ten equipment error závislé na řadiči GM82C765B....

Tak odpovím si sám, protože jsem našel v datsheetu Intel 8272 toto:

Doporučená hodnota tam je 27 (1Bh) při GAP3 84 (54h). Takže ve Skalici asi experimentovali, a aby to "nějak" chodilo i s GAP 35, tak dali hodnotu 10.

Udělám tedy takový pokus. Datasheet tvrdí (pokud to tedy správně chápu...), že by nemělo dělat problém při GAP3=84 (54h) až 15 (0Fh) sektorů na stopu. No tak odstraním ten test na počet stop a nastavení malé GAP3 u formátu a uvidíme...

Aha, vdaka za upresnenie. Formatovanie na MDOSe 2 som nejak moc nestudoval (a ani v tom intel radici sa az tak nevyznam), zato som vela robil s radicom WD2797 ktory je v D40 a aj v MB02.

MDOS1 formatuje vzdy rovnake gapy, bez ohladu na pocet sektorov takto
(ak som to spravne pochopil zo zdrojaku):

Zaciatok stopy po indexe: nic
Kazdy sektor: gap 25 + znacka + gap 37 + data + gap 40 bajtov
Koniec stopy: gap 512

Teda sumarny celkovy pocet gapov na sektor je 102 bajtov. Pritom na stopu sa krasne vojde aj 10 sektorov,
Stopa s 10 sektormi po 512b zaberie dokopy 10 * (25 + 1 + 4 + 2 + 37 + 512 + 2) = 6240 bajtov.

Pre zaujimavost, na MB02 formatujem disketu takto:

Zaciatok stopy po indexe: gap 50
Kazdy sektor: znacka + gap 22 + data + gap 44
Koniec stopy: gap az do konca buffera v pameti (skratka vela)

Stopa s 5 sektormi po 1kB zaberie dokopy 50 + 5 * (1 + 4 + 3 + 22 + 1 + 1024 + 2 + 66) = 5660 bajtov
6 sektorov 1kB sa na DD disketu uz nevoslo, co som pozeral diskety tak do fyzickeho konca magnetickej stopy je este nejakych cca 600-700 bajtov.

Pri HD diskete je to lepsie, tam sa voslo 11 sektorov 1kB na stopu.
11 * (1 + 4 + 3 + 22 + 1 + 1024 + 2 + 66) = 12392 bajtov

Vyhlašuji malou výzvu pro codery
Hodilo by se mi to zkrátit o 1 bajt. Nic kromě registru A to nesmí měnit, na výstupu je jedno co v A(F) bude. Zásobník lze využít pokud to pomůže...

Má to 19 bajtů, já potřebuju max. 18

Inlinuj tu rutinku tam odkial sa vola a usetris nielen zaverecny RET ale popripade aj cely CALL.

Rozumím, ale toto není v tomto případě možné. Bohužel.
Jako opravdu v nejhorším použiju jinou barvu okraje. Ale třeba někdo vymyslí řešení

Skus sem napisat sirsi kontext tej rutinky, odkial z akeho kodu a preco ju volas, nech o tom vieme viac. Potom je vecsi priestor na optimalizaciu.

Neplníš tu PAMET ještě v jiné části programu

ld (PAMET),a
ret

že by jsi na to skočil?

_________________
Praxe znamená, že vše funguje, ale nevíme proč. Teorie znamená, že vše víme, ale nic nefunguje.
Někdy je teorie spojena s praxí. Znamená to, že nic nefunguje a nikdo neví proč ...

Velmi bude tvoje OCD boliet pri farebne blizkej farbe bordera?

Joooo, to by se dalo zařídit.... No vida jaké jednoduché řešení. Dík moc za nakopnutí!

Hustý teď jsem spoluautorem MDOSu.

_________________
Praxe znamená, že vše funguje, ale nevíme proč. Teorie znamená, že vše víme, ale nic nefunguje.
Někdy je teorie spojena s praxí. Znamená to, že nic nefunguje a nikdo neví proč ...

budeš v komentáři ve zdrojáku