OldComp.cz

Mikes21 napadlo mne zda by se na Sharpovi nezacal delat projekt kde by z nejakeho uz hotoveho kitu kde je dostatek pameti se emulovala fyzicka mechanika. Optimalizace projektu by se udelala pozdeji. Cele bych si to predstavoval ze na klicove signaly jako je RD s WR do mechaniky a samozrejme i ostatni by vedlo do FPGA pres nejaky CPLD. Idelane Xilinx 5V tolerantni. FPGA by snimkovalo signal WR 2x rychleji nez je bezne a tak by to bezelo na 4MHz. Rychlost snimani by teda byla 125ns. Jedna bezna disketa ma na stope cca 6250 bajtu surovych dat a tak celkem to dela na 80 stop a dve strany 1MB (DD 720KB). U nas by to delalo 2MB. Takze surova kopie diskety by mela 2MB dat. Muzeme si to predstavit jako wav soubor ale je to samozrejme neco uplne jineho.

Cele reseni by bylo udelane tak ze uvnitr by byl jeden velky citac co by cital jednu stopu. Presne na zacatku stopy by na primerenou dobu daval signal Index. Takto by se radic synchronizoval a ve spravou dobu pri zapisu by zmenit signal WE a podle citace by FPGA zapisovalo binarne data do prislusne casti pameti. Cteni by bylo uplne jednoduche to by jen neustale dokolecka davalo data na RD podle obsahu pameti pro prislusnou stopu.

Kdyz by se overilo ze toto reseni je schudne tak by se to dalo pouzit i pro QD a CMT. Mozna vyhledove i pro HDD.

Mne by se toto libilo, hlavne ze by to byl otevreny system s moznosti zmeny a samozrejme plne pouzitelny i na jinych strojich. Protoze by to nekoukalo na data, tak by se nemuselo hodne veci ani resit. V budoucnu by mohl nekdo udelat sw kde by napr. ze souboru .dsk udelal tuto binarni kopii a naopak. Na to bych videl idelani jazyk C#. Je jasne ze hlavni uloziste obrazu disket by bylo PC a tam by se to prenaselo asi pres RS232. Druhe reseni by byla nejaka Flash s velkou pameti - rizene ze Sharpa.

Jako bonus bych si predstavil ze bych to napojil na cteni z CMT a tam bych byl schopen vypipat data jako tri MZF soubory za sebou. Vzdy s mezerou treba 3s mezi soubory. To by mohla i ovladat nejaka CP/M. Takze FPGA by bylo pripojeno k Sharpovi pres port. A zde by sla dobre pouzit ta nase DMA karta. Co na to rikas, ma to hlavu a patu?

To co jsem psal bylo vhodne jen pro FM kodovani. Pro MFM musime mit 1 us snimani a tak minimum je 4MB. Pro idelani stav je vhodne ukladat zmeny kazdych 62,5 ns, to je dokonce 64 MB.

Nasel jsem pekny VHDL dekoder "Floppy disk controller with all features of the Western Digital WD1772-02 controller" a toho by slo pekne vyuzit pro zmenseni dat.

pekna idea az na ten "idealni" jazyk c#. radeji neco, co pojede na vice platformach...

Nevim, jestli to ma hlavu a patu, tak jen par postrehu.
Predevsim by bylo potreba vyresit to, jak takovou periferii pripojit na Sharpa (nebo neceho jineho). Protoze to CPLD musi vyresit adresovani dane periferie. Pro CMT to mohou byt jen dva draty (pro externi kazetak) nabo neco navic (motor start/stop) pro interni kazetak, ale pro FDD a QD to uz bude adresova, datova a ridici sbernice CPU. Pak se musi implementovat alespon nektere registry dane periferie. Treba u WD radice jsou to datovy ger., registry stopy, sektoru, strany a urcite nejaky status registr. Pro QD to budou registry Z80-SIO. Teprve potom nasleduje vlastni logika fungovani periferie. Ta je pro FDD, QD a CMT docela hooodne odlisna. Nasleduje nejake medium pro ulozeni dat, treba FLASH pamet. Zminovany citac, ktery bude jeho soucasti, je uz docela 'brnkacka'. No a na 'velke finale' nejaky ten file management, proste neco, jak tam nahravat data a jak je zase ziskat zpet.
Mimochodem, nejjednodussi by byl externi kazetak. Proste mp3 prehravac, linkovy vystup a 'tradaa'. Vyzkouseno, tohle funguje celkem v pohode. Je to skoro jako propojit dva Sharpy do krize kazetak x kazetak.
Ale, jak rikam, jako "PoC" nevim jestli to ma hlavu a patu. Na to nejsem manazer.

_________________
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

Mikes21 urcite CMT je nejtrivialnejsi pripad ale zde uz je to castecne vyresene pres loading z pc pres RS232. U QD je teoreticka moznost ze by to take takto slo. Rychlostne je to presne na hrane. Muj projekt by sel dale kam uz RS232 nemuze jit. Pri 1 us snimkovani je potreba 1 MHz. Urcite bych chtel pro zacatek pouzit beznou CP/M disketu 720KB. Ta ma na jedne stope 6250bajtu +-150 bajtu (2% tolerance). Pro MFM muze zmena prijit kazdych 2us. Kdyz je zmena tak je videt cca 250ns impuls od radice. To zmeni polarizaci, coz v nasem pripade nebude nic jineho nez zmena z log0 na log1 a naopak. Zapis se aktivuje pri WE do log0. To dela jen to ze na disketovou jednotku se zapisuje stale stejna polarizace, v nasem pripade stale stejna logicka hodnota.

Mikes21 my nebudeme vubec koukat na bezne porty, treba FDD radice. My budeme zpracovavat signaly co jsou na 34 pinovem konektoru smerem k mechanice. Kdyz se to povede tak budeme mit system co se da obecne pouzit. Napr. pro Zetu ci jiny pocitac.

Kdyz to napisi jinak, tak na jedne stope je 50 000 bitu. Potrebujeme evidovat 100 000 useku, kde muze prijit impuls od radice. To je celkem 12500 bajtu. Taktovych stop mame 160 a tak celkova kapacita jedne 702KB diskety je 2MB surovych dat. Protoze jedna stopa ma 12500 bajtu a tu musime ulozit/nacist do 3ms, coz je nejrychlejsi emulace krokovani FDD tak na jeden bajt mame 240 ns, coz je dost casu. Nesmime zapomenout ze potrebujeme pri krokovani jak ukladat, tak cist a tak je to 120 ns/bajt. FPGA bude mit v pameti vzdy jen jednu stopu. Vzdy kdyz se provede seek, tak se soucasna ulozi a nova nacte. Kdyz by se nejakou delsi dobu nedelal zadny zapis do mechaniky tak by se automaticky zapsala posledni stopa do flash.

Ve vetsine pripadu kdy se roztoci motor bude fpga neustale dokolecka vysilat data na RD signal do radice pro prislusnou stopu.
Jak prijde signal WE tak zacne zapisovat log0 (nebo log1) a pri kazdem impulsu to zmeni. Jak prijde WE do log1 tak prestane zapisovat. Na RD se neustale bude ukazovat spravne data pro stopu. O spravne nacasovani zapisu se samozrejme bude starat radic jako je to u bezne mechaniky. My nebudeme urcovat kdy se co zapisuje. My to jen provedeme.

Jinak pro zacatek to musime udelat nejak trivialne a nemuzeme si vymyslet nejake vychytavky, jinak ten projekt zabijeme.

V cem jsou nevyhovujici dostupne emulatory FDD? (napr. gotek) Ty prece delaji to same, akorat krome flash maji kartu s filesystemem...

Obecne tam vidim par problematickych veci:
- synchronizace hodin FPGA a radice - bude tam muset byt nejake DPLL, ktere bude udrzovat samplovaci rychlost pri zapisu synchronni s prubehem signalu
- rychlost prenosu dat z pameti FPGA do externi Flash pameti a nacteni dat pro novou stopu - proc nepouzit dostatecne velkou externi SRAM?

Tak v tom pripade Basic.

Hlavni nevyhoda je ta, ze Gotek neni otevreny system. Dalsi podstatna vec je ze na 99% to nezvladne to ze Sharp ma prvni stopu formatovanou jinak nez PC.

hynek pise: "- synchronizace hodin FPGA a radice - bude tam muset byt nejake DPLL, ktere bude udrzovat samplovaci rychlost pri zapisu synchronni s prubehem signalu"
Proc? Kdyz budu samplovat rychlosti 61,5 ns tak mam 32 samplu za jeden 2 us usek. Kdyz alespon jednou tam bude log0 tak to znamena ze v tomto useku se ma zmenit polarita zapisu. V pripade ze se to neosvedci, tak hrubou silou udelam 2x vice useku a jeden usek bude dlouhy 1 us a tak to vzdy bude fungovat ale bude to logicky 2x vice dat (Shannonův teorém nebo https://cs.wikipedia.org/wiki/Vzorkovac%C3%AD_frekvence). Jak radic, tak FPGA, kazdy jede ve sve hodinove domene a nebude se to synchronizovat. Radic jede 32x pomaleji. Ocekavam ze rozestup mezi impulsy budu mit 4, 6 nebo 8 us. Takze tech impulsu neni az zas tolik . Uvidime co ukaze praxe.

hynek pise: "rychlost prenosu dat z pameti FPGA do externi Flash pameti a nacteni dat pro novou stopu - proc nepouzit dostatecne velkou externi SRAM?" samozrejme ze to asi zacnu na desce s velkou pameti ale jako konecne reseni to ted neni vhodne. Ty kity stale stoji hodne penez. Lepsi bude nejaky za 700Kc plus nejaka flash pamet.

Hlavni vyhoda by byla ze by to mohlo casem precist i jinak nepouzitelne diskety a ty zpracovat. System bude pouzivat jen log0 a log1 a to se bude i tak v case ukladat. System nebude se snazit pochopit co prenasi a zda data maji smysl. Je jasne ze v pocitaci se i tyto surove data (raw) daji sw zpracovat. Je jasne ze sw muze i tyto surove raw data z jinych vytvorit, treba z .dsk.

1. Ale vzdyt schema od Goteka mame, typ procesoru taky, ma vyvedene piny pro flashovani. Takze psani vlastniho fw nic nebrani.
2. A proc by to nezvladlo jinak formatovane kterekoliv stopy/sektory? Pokud by fw korektne nacital a vyuzival data z .dsk souboru, tak podle toho muze posilat data na FDD rozhrani. Pokud by Sharp (nebo neco jineho) zapisoval sektor, tak taky. A pokud by bezelo formatovani ze Sharpa do emulatoru FDD, tak by fw parsoval hlavicku kazdeho sektoru a podle toho by vytvarel hlavicky v .dsk souboru. Nasledne by podle toho ulozil data do sektoru.
Ja bych to videl tak, ze by to, potencialne, melo bezet nad vsemi byty cele stopy. Ta by mela mit cca 10kB vcetne gap, header a data.
Skoro bych rekl, ze to neni o hw takoveho emulatoru, ale o sw pro uz existujici hw (Gotek). Jen je otazka, kdo se do toho pusti a udela to.
suksoft: Ted mi doslo, co tim "provokovanim" tady myslis. Ale nic ve zlem.

_________________
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

A opravdu to chcete a máte čas psát, když se to dá za 10 EUR koupit? http://www.8bity.cz/2015/hxc-software-p ... tor-gotek/

Teda GOTEK s HXC firmwarem jsem zatím na Sharpovi nezkoušel, ale s ohledem na to, že mi tam funguje klasický HxC floppy emulátor s HFE nevidím důvod, proč by nemělo.

_________________
http://www.8bity.cz

Podle me jde Radkovi o univerzalni (FD,QD,CMT, ev. dalsi) otevrene reseni.

Mikes21 s celym tvym prispevkem souhlasim ale je to uplne jiny projekt a asi v soucasne dobe je to pro mne nesmysl.
Kdyz by to bylo tak lehke tak to jiste je uz udelane. Ja osobne nepujdu cestou programovat Gotek. To necham na jinych. V pripade ze se ukaze cesta logickeho obvodu v FPGA jako nerealna, tak spise se budu snazit rozjet Z80 pod FPGA a udelat tam program pro Z80 a vyuzit toho ze to pojede rychleji nez realny Z80. Ale ani toto neni na poradu dne.

Jedna z uvah a nejenom moje, je udelat http://hxc2001.free.fr/floppy_drive_emulator/ a zde se inspirovat. Projekt neni prilis drahy a vse se da v Cine bezne koupit. Deska (10 kusu) by prisla na 25 USD a soucastky urcite do 200-250 Kc.

Dalsi uvaha kterou ma konkretne Uunek, je zacit s CMT. Mate nekdo presny prubeh signalu pro dvojnasobnou rychlost nahravani a trojnasobne nahravani? Z toho by se dala odvodit rychlost jakou vzorkovat signal. Napr. pri vzorkovani 10 000 vzorku/s to dela 1250 bajtu na 1 s a cela 90 min kazeta se vejde do souboru o velikosti 7MB. Zde je vzorek kazdych 100 us. Mozna je to mala frekvence vzorkovani a treba bude nutnost delat to kazdych 10 us ale pak data budou samozrejme 10x vetsi.

Prvotni pokus by mel byt neco jednoducheho, autonomniho, bez potreby nejakeho externiho systemu. Treba jen dve externi tlacitka Record a Play. Pro zacatek pouzit vzorkovani kazdych 40 us. Cele bych si to predstavoval jako jeden velky citac co by neustale jen cital. Kazdy bit by zapisoval do presne urceneho bitu pameti. Pameti bych mel pro zacatek 2 MB, abych to mel jednoduche. Toto by mohlo nejdrive nahrat az 6 minut kazety a pak to prehravat dokolecka.

Ja chci jen zapsat sled jednicek a nul a to zpetne prehrat, nic vice ani o nic mene. Precte te si muj prvni prispevek.

V servisnim manualu je uvedene:
short = 240us H / 278us L
long = 470us H / 494us L
read point @ 379us
to je 139us po hrane short a 91us pred hranou long.

Zminovane vzorkovani 40us bude rozumne pouzitelne maximalne pro tuto zakladni rychlost.
Je potreba si uvedomit, ze vzorkovany signal muze mit posunutou hranu o temer 40us, pokud se v jednom vzorku sejdou dve takove hrany, tak se zmerene casovani zmeni o 80us, coz uz muze vest k nespolehlive detekci...

Pro 3x rychlost plati nejspis 3x kratsi casy a z toho vyplyvajici pozadavky na vzorkovani signalu.

Vzdy je lepsi vedet, jaky signal tam ma byt a synchronizovat se na nej - tim se zvysi spolehlivost a snizi datove naroky. Jinak bych videl jako rozumne zvolit takove vzorkovani, aby se hrany pri nejvyssi rychlosti mohly vzajemne posunout tak maximalne o 10%...

Jeste jsem o tom trochu premyslel...
Pokud mam audiodata ulozena ve wavu - tj. 8-/16-bitovou uroven jednotlivych vzorku, je snadne zrekonstruovat presnou polohu hrany i s nizsi vzorkovaci frekvenci. Pokud bude vzorkovani 1-bitove, tak se ta presnost musi dohanet vyssi vzorkovaci frekvenci...

Pokud budu uvazovat nejkrasi cas 240us, vzorkovani 10x rychlejsi (tj. cca 40kHz a jitterem rekonstruovaneho signalu +- 50us, coz v zavislosti na detekcnim algoritmu uz nemusi byt spolehlive), mam datovy tok 5kB/s. Skutecny datovy prenos ale bude cca (150-300)B/s, tj. 16x az 33x nizsi (neda se to urcit, protoze doba prenos 1 a 0 je ruzna... i kdyz se casto uvadi 1200Bd)

Take jsem na tom vcera premyslel. Nasel jsem http://www.scav.cz/download/MZ-800/MZ-8 ... mt-800.txt kde jsou tri casy nahravani.

Speed1=551 ;rychlost 1/1 (rychlosti)
Speed2=311 ;rychlost 2/1 (podle Turbo)
Speed3=231 ;rychlost 3/1 (Copy)

Ty casy se davaji do casovace a tak je to pomerove meritelne.

Hynku urcite nemas pravdu ze realny prenos je jen 150-300B/s. Dukaz je muj prvni program pro Sharpa co jsem pouzil v zivote a to zakladni Basic. Ten ma delku 46164 bajtu a nahrava se 5 minut, takze nejakych 300 s. To je rychlost nacitani 1231 bajtu/s.

To ze wav uklada analogovych hodnotu vzorku je hezke ale Sharpa to vubec nezajima. Jeho zajima jen log0 a log1, nic mezi tim neni. Bavime se o vnitrnim konektoru T5. Dulezite je ten jitter jak pises, to je klicove. Kdyz se zvetsi frekvence snimkovani tak se snizi jitter.

Pro rychlost 3/1 se da predpokladat ze impuls Short je log0 po dobu 140 us a meri se v dobe 70 us. Takze muj navrhovany interval 40 us by mohl vyhovovat. Kdyz se snimkovani posune o 40 us (nejhorsi pripad co muze nastat) tak stale jeste nacte log0 a tak se to spravne vyhodnoti.

Vse se samozrejme musi otestovat v praxi.

No nevím, ale zní to jako popis diktafonu, který nahráva do WAVu. Ten se dá napojit rovnou na jack konektory v zadu na Sharpovi. Převod zpět na 1/0 provede komparátor na vstupu Sharpa a hranu vrátí na správné místo, kam patří. Vyhoví všecko, co ukládá aspoň 8bit při 22k vzorcích za sekundu.