OldComp.cz

Komunitní diskuzní fórum pro fanoušky historických počítačů


Právě je 28.03.2024, 11:26

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]


Pravidla fóra


Do názvu vždy zadávejte platformu, které se téma týká!



Odeslat nové téma Odpovědět na téma  [ Příspěvků: 16 ]  Přejít na stránku 1, 2  Další
Autor Zpráva
PříspěvekNapsal: 22.02.2022, 18:29 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 89
Has thanked: 3 times
Been thanked: 48 times
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


Nahoru
 Profil  
 
PříspěvekNapsal: 22.02.2022, 18:49 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 21.01.2021, 11:05
Příspěvky: 1581
Bydliště: Pardubice
Has thanked: 25 times
Been thanked: 238 times
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č ...


Nahoru
 Profil  
 
PříspěvekNapsal: 22.02.2022, 19:37 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 89
Has thanked: 3 times
Been thanked: 48 times
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.


MilasPce píše:
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)


Nahoru
 Profil  
 
PříspěvekNapsal: 22.02.2022, 20:02 
Offline
Profík

Registrován: 06.03.2018, 16:00
Příspěvky: 955
Bydliště: Valtínov, Kunžak
Has thanked: 39 times
Been thanked: 471 times
Něco málo o ukládání dat na pásku pod CP/M pro MZ-800 je tady

P.


Nahoru
 Profil  
 
PříspěvekNapsal: 22.02.2022, 20:35 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 89
Has thanked: 3 times
Been thanked: 48 times
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í)


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

P.


Nahoru
 Profil  
 
PříspěvekNapsal: 22.02.2022, 21:57 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 89
Has thanked: 3 times
Been thanked: 48 times
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".


Nahoru
 Profil  
 
PříspěvekNapsal: 22.02.2022, 23:42 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 12.05.2013, 21:39
Příspěvky: 1969
Bydliště: Praha
Has thanked: 85 times
Been thanked: 255 times
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.


Nahoru
 Profil  
 
PříspěvekNapsal: 23.02.2022, 00:44 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
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


Nahoru
 Profil  
 
PříspěvekNapsal: 23.02.2022, 00:50 
Offline
Profík

Registrován: 06.03.2018, 16:00
Příspěvky: 955
Bydliště: Valtínov, Kunžak
Has thanked: 39 times
Been thanked: 471 times
Doda píše:
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.

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.


Nahoru
 Profil  
 
PříspěvekNapsal: 23.02.2022, 08:45 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 89
Has thanked: 3 times
Been thanked: 48 times
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.

suksoft píše:
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


Nahoru
 Profil  
 
PříspěvekNapsal: 23.02.2022, 11:35 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 89
Has thanked: 3 times
Been thanked: 48 times
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


Nahoru
 Profil  
 
PříspěvekNapsal: 23.02.2022, 16:11 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 89
Has thanked: 3 times
Been thanked: 48 times
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


Nahoru
 Profil  
 
PříspěvekNapsal: 28.03.2022, 16:24 
Offline
Radil

Registrován: 24.12.2014, 16:11
Příspěvky: 424
Has thanked: 31 times
Been thanked: 100 times
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:
Kód:
https://webshare.cz/#/file/EGUUGRSMVe/cp-m-pdf


šířeno se svolením autora


Nahoru
 Profil  
 
PříspěvekNapsal: 12.12.2023, 23:16 
Offline
Pan Štábní

Registrován: 11.11.2013, 10:29
Příspěvky: 1198
Has thanked: 359 times
Been thanked: 304 times
omikron píše:
šíř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


Nahoru
 Profil  
 
PříspěvekNapsal: 13.12.2023, 00:06 
Offline
Radil

Registrován: 24.12.2014, 16:11
Příspěvky: 424
Has thanked: 31 times
Been thanked: 100 times
Býval lec zavináč lec tečka cz


Nahoru
 Profil  
 
Zobrazit příspěvky za předchozí:  Seřadit podle  
Odeslat nové téma Odpovědět na téma  [ Příspěvků: 16 ]  Přejít na stránku 1, 2  Další

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]


Kdo je online

Uživatelé procházející toto fórum: Žádní registrovaní uživatelé a 4 návštevníků


Nemůžete zakládat nová témata v tomto fóru
Nemůžete odpovídat v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete přikládat soubory v tomto fóru

Hledat:
Přejít na:  
Založeno na phpBB® Forum Software © phpBB Group
Český překlad – phpBB.cz