OldComp.cz

Prosím, nemáte náhodou někdo popis formátu, ve kterém se ukládají soubory z cp/m na magnetickou pásku?

V cp/m se nachází program tape.com - experimentuju s MZ-800, nicméně předpokládám, že ten formát bude v rámci různých cp/m kompatibilní.
Zkouším nejprve rozlousknout fyzický formát a následně ten logický. Prozatím se mi moc nechce jít do toho, že bych ten tape.com dissassembloval a krokoval, takže analyzuju WAV, který obsahuje save souboru, jehož obsah znám.

Prozatím jsem zjistil, že se ke kódování ve fyzickém formátu plně využívá celá délka pulzu a nikoliv jen ta kladná, jako je tomu např. u nativního CMT formátu MZ, nebo u ZX.

Tipuju, že by se popis formátu mohl vyskytovat např. v dokumentaci k nějakému slušovickému systému, nicméně rád si počtu i v něčem, co třeba jen vzdáleně připomíná tento formát.

Ve fyzickém formátu se vyskytují 4 druhy pulzů v závislosti na tom, jaký je poměr kladné a záporné půlvlny: short1 + short0, short1 + long0, long1 + short0, long1 + long0.

Pilotní tón je složen z opakujících se sequencí long1 + short0 a short1 + long0.

Vyhledal jsem si zpusob, jak se enkódují některé číselné hodnoty a vypadá to, že pro jeden byte je vyhrazeno 8 celých pulzů.

0x00:
short1 + short0,
short1 + short0,
short1 + short0,
short1 + short0,
short1 + short0,
short1 + short0,
short1 + short0,
short1 + short0

0x01:
long1 + long0,
short1 + short0,
short1 + short0,
short1 + short0,
...

0x02:
short1 + short0,
long1 + long0,
short1 + short0,
short1 + short0,
...

0x03:
long1 + short0,
short1 + long0,
short1 + short0,
short1 + short0,
...

0x04:
short1 + short0,
short1 + short0,
long1 + long0,
short1 + short0,
...

0x05:
long1 + long0,
long1 + long0,
short1 + short0,
short1 + short0,
...

0x06:
short1 + short0,
long1 + short0,
short1 + long0,
short1 + short0,
...

0x07:
short1 + short0,
short1 + short0,
short1 + long0,
short1 + short0,
...

0xff:
long1 + short0,
short1 + short0,
short1 + short0,
short1 + short0,
short1 + short0,
short1 + short0,
short1 + short0,
short1 + long0

Přijde mi to takto:

short1-short0 bit je 0
long1-long0 jeden bit je 1
long1-shot0 budou jedničky které skončí short1-long0. ale bity mezi budou short1-short0 kvůli zvětšení rychlosti přenosu (pouze u bloku jedniček u bloku nul to nemá význam zrychlovat)

_________________
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č ...

Jasně, nicméně tam jsou ještě některá další dost podstatná specifika, která se dost těžko odhadují pozorováním metodou pokus / omyl a tak bych k tomu rád získal nějaké povídání.

Např. 3 po sobě jdoucí bajty s hodnotou 0xff jsou takhle enkódovány jako souvislý blok 24 bitů.

Navíc to vypadá, že poslední datový byte je okraden o poslední pulz (v kontextu to asi i dává smysl).
Tento "ukradený" pulz je použit jako nultý bit pro závěrečný 9 bitový sumární součet jedniček.

Něco málo o ukládání dat na pásku pod CP/M pro MZ-800 je tady

P.

Pěkný popis cp/m. Na str. 87 - 88 je sice popsaný CMT formát, ale jedna se zjevně o nativní MZ-800 formát, u kterého se fyzicky používá jen kladná polovina pulzu (fyzický formát zná dva stavy short1, long1 a délka druhé poloviny pulzu je irelevantní)

Dostal jsem od kamaráda tip na to, že by ten fyzický formát mohl být podobný s tím co používá nativně PMD-85 https://pmd85.borik.net/?action=download&did=115 - strana 55.
Xorují se tam hodiny (1) s odesílanými daty (9) a výsledek (3) je dost podobný tomu mému popisu - akorát oni mají short + short při hodnotě "1".

Nikde ve standardu cp/m neni popis formatu pro pasku, takze to urcite bude proprietalni implementace. Je to stejne unikatni jako napriklad implementace pro microdrive na ZX Spectru.

Chaky asi to moc nepomuze ale nekdo mozna ma nejaka data v odkazech

http://www.mz-800.scav.cz/sharp_mz-800/ ... _M_v22.htm

zde je odkaz na msave.mac a mload.mac
http://www.mz-800.scav.cz/download/MZ-8 ... /Files.txt

Mozna nekdo ma ty zdrojaky.

======

take by temohlo zajimat:
TAPE .COM - 155 sectors 5 empty 20K 70K ;Přenos CP/M-MGF,blbne!(S)
CMT .COM - 28 sectors 4 empty 4K 74K ;Přenos CP/M-MGF,blbne!(S)
CMT3 .DOC - 54 sectors 10 empty 8K 82K ;Popis CMT

Ano, přesně tak a proto je tam část BIOS, která má na starosti vlastní komunikaci s konkrétním HW. CP/M jen zavolá příslušnou službu v BIOSu s odkazem odkud data uložit nebo kam je načíst a je mu (CP/M) úplně jedno, jak to BIOS udělá. Takže každá implementace BIOSu může být (a nejspíš i je) zcela unikátní. I já si můžu napsat služby pro práci s kazeťákem a způsob, jakým ta data na pásku dostanu, bude zcela na mě. Definovaný je pouze způsob přenosu dat mezi CP/M (potažmo BDOSem) a BIOSem, ale konkrétní uložení dat na fyzické už závisí jen na BIOSu. Nemůže tedy existovat pouze jeden univerzální způsob uložení dat na fyzické médium.

P.

Vidíš Radku, tolikrát jsem tenhle dokument v životě četl a zrovna tahle část mi z něj nějak neutkvěla v paměti

Každopádně začínám tušit, že jsem si malinko naběhl na lopatu. To co tady analyzuju je formát o kterém Intercopy tvrdí, že je cp/m. Z doposud získaných indicii mám pocit, že by to tedy mohl být cp/m formát z právě již zmiňovaného PMD-85, k čemuž mohl mít Marek Šmihla - autor Intercopy přece jen blíže.

EDIT: teď jsem mluvil se Zdenkem Adlerem a ten mi potvrdil, že tape.com pochází z CP/M Yoshin&Vector - takže by se mělo jednat o SharpMZ specifikum.

Tak ten závěrečný součet není ani zdaleka jen 9 bitový!
Takhle vypadá konec 16 bajtového bloku, který obsahuje na začátku 3x 0xff a jinak samé nuly:

// tady zacíná zkrácený poslední bajt
short1 + short0,
short1 + short0,
short1 + short0,
short1 + short0,
short1 + short0,
short1 + short0,
short1 + short0,
long1 + long0, // první bit kontrolního součtu

long1 + short0,
short1 + short0,
short1 + short0,
short1 + short0,
short1 + short0,
short1 + long0,
long1 + long0,
short1 + short0

3 * 0xff = 0x2fd = 0010 1111 1101

Takže hotovo - zde je formát:

- pilot je složen z opakující se sequence 110 (long + short, short + long)
- začátek bloku je identifikován jako 111 (long + short, short + short, short + long)
- následuje 1 bajt - 0x00 = header, 0x01 = body

- odsud buď pokračuje blok 128 bajtů, v němž je klasický MZ header, nebo blok s daty (tento blok je zkrácen o poslední bit!)

- za blokem následuje obyčejný 16 bitový součet (z jeho výsledku určíme hodnotu posledního bitu z bloku)

- celé je to uzavřeno separátorem v podobě jednoho long pulzu


long + long = znamená 1, 0

long + short,
( libovolný počet short + short),
short + long = znamená 1, (libovolný počet 1), 1, 0

short + short = znamená 0

Jestli je to CP/M od Jiřího Lamače - LEC

tak formát záznamu je shodný se SAVE "neco" CODE na ZX Spectru. Nahrávaný soubor je rozsekaný na kousky po 32KB a každý je uložen jako samostatný blok. A do normálně nevyužitých bajtů v hlavičce je uložen poslední byte názvu, neboť Spectrum má jen 10 zn. a CPM 8+3, a pořadové číslo 32KB bloku.

Celé je to popsáno zde:


šířeno se svolením autora

Koho myslis tim autorem, Jiriho Lamace nebo 602 ZO Svazarmu? Pokud J.L. tak byl by na nej jeste dnes kontakt? Ptam se protoze od nej bylo i nekolik disket sw a zdrojove kody, tak by me zajimalo jestli by byly k dispozici. Popripade i se svolenim autora. A v tom archivu byl i sw pro MZ-800.

_________________
Sharp MZ-800++, MZ-1500++, MZ-2500++, SM-B-80T, MK-14_replica, HP-85, ZX-80+replica, ZX81, ZX-Spectrum+replica++, PMI-80+replica, SAM coupe++, PMD-85-2A+3, Didaktik-M, SORD-M5, TI-57, TI-59+PC-100, TI99/4A, ZetaV2+ppp, ZX-uno, Petr, SAPI+

Býval lec zavináč lec tečka cz