Ahoj, netušíte někdo, kde sehnat v kusovce brouky od fairchild? Zajímá mě především http://www.fairchildsemi.com/pf/FM/FMS6403.html , což by byl ideální materiál pro konverzi sharpího RGB(I) na komponentní YPbPr (což v dnešní době považuji za smysluplnější než scandoubler), ale i nějaké další. Ctirad
Ctirade,
nezbývá než zagůglit, já to ve své tvrdohlavé snaze sehnat WD2791
(resp. WD1773 - kusovku) dělám zrovna tak. Vypadá to na nákup z ciziny.
Sám nevím, jak to dopadne ...
Sháněl ses po schematu FDD s tím, že to mé je "čitelné".
Je na Zdeňkových stránkách na:
http://mz-800.xf.cz/files/tech/MZ-FDD.bmp
Šlo by to i jednodušeji (při nasazení kýženého 2791):
-odpadá invertor datové sběrnice U2
-je-li FDD v celku s jiným HW, lze získat selekční signály z vhodného IC,
pak odpadá i U3
-při krystalu 2MHz odpadá U5A (využije se jako registr pro \'MOTOR ON)
-při zamhouření obou očí lze vynechat i budič U4
-za předešlých podmínek lze nahradit U7 a U8 jediným obvodem 74xxx137
K té emulaci FDD jednočipem a SD kartou:
Já jsem pro realističnost emulace. Pozdržet program a tím vykonat
"seek" přece není pro programátora rutinéra problém (?). Nic moc
se totiž neušetří.
Pro srovnání:
Měřil jsem dobu načítání Flappyho (od nápisu "IPL is loading Flappy"
do okamžiku spuštění hry - zčernání obrazovky) z CMT: běžnou rychlostí
1/1 1200b/s ---> 246s. Totéž z diskety (od nápisu "IPL is loading
LAMAC CP/M" s následným rychlým vyťukáním funkčními klávesami
"CM R FLAPPY") ---> cca 12s. To je úspora 234s (20x rychleji).
Oproti tomu zerowait FDD emulace ušetří pár se kund s tím, že nelze
předvídat chování programů (i CP/M, Basicu, hlavně jejich utilit atd.).
Toť můj skromný názor. Osobně mám raději pravý hardware pro svou
zábavnost, na desce s jednočipem si ji neužiju. Ale taky je to jedna
z možností lidové tvořivosti.
Petr de Zviqov
> Mimochodem, ač se chystáte použít rychlý procesor, tipnul bych si že bude výhra, > když se při současné obsluze SD karty s FAT podaří aspoň dosáhnout rychlosti > běžné floppy. Každopádně, těším se na tenhle kousek HW jako malé děcko :) >
Zdenku, tam nejde o rychly procesor. Ale o dostatek datove RAMky, kde si muzes udrzovat metainformace pro 4 emulovane disketove mechaniky a nejlepe 4 SD sektory 512B (jeden pro kazdou mechaniku), se kterymi se aktualne pracuje. At se da rozumne zapisovat. Urcite vis, ze SD karta je sekvencni medium, abys mohl zmenit jediny bajt, musis precist a zapsat cely sektor (ostatne, stejne jako FD). Samotne 4 datove sektory zaberou 2kB pameti. Metainformace pro HD disketu taky zaberou nejake misto. A najednou jsi bez pameti. Co se tyce rychlosti, myslim, ze by stacila dalsi Z80ka, kdyz bude mit pripojeno aspon 8kB RAMky. Cokoli rychlejsiho je jen vyhodou. Ale jaka je rychlost u soucasne implementace s AVR v praxi, to musi napsat Michal... V. PS: Jeste jednou jsem se dival na tu ATMEGu8 - zrejme by se dalo pouzit port D, pricemz clovek prijde o interrupty. A ja je mel v me puvodni verzi pouzite, to je pravda. SD kartu pripojit na PB2-PB5 a tech par ridicich signalu se taky najde. Takze z tohoto pohledu by pro tu low-cost verzi stacila ATMega8, XC9536, 74HC245. A jak psal Petr, fungovalo by to tim zpusobem, ze z emulovaneho ROMdisku nabehne "spravce souboru" na SD karte, uzivatel vybere MZF, zmacne CR a jedeme. V podstate jako kdyz nabootoval CP/M a spustil program skrz MZRUN.
OK Vašku, jistě víš o čem píšeš.... Jenom mi přišlo, že když dám na Sharpovi požadavek na přečtení sektoru a budu očekávat první bajt, tak AVR si musí poradit s: 0. zpracování příkazů pro řadič, neustálé odpovídání na status 1. čtení z FAT 2. zvládnout strukturu DSK souboru 3. datové přenosy SD -> SRAM, SRAM -> sběrnice Sharpa 4. ....... a plno dalšího co ani nedomýšlím Jednoduše mi připadne že WD řadič musí vítězit minimálně v přípravě prvního bajtu z každého sektoru. Ale je fakt že já skončil u procesorů na bázi 8051 s výkonem do 33 MIPS které jsem programoval v C a vím že u nich jsem občas narážel právě s rychlostí (např. když jsem dělal hardwarovou emulaci Soundchipu SHARPa). Věřím že při dnešních možnostech - např. hardwarové SPI rozhraní u AVR, rychlejší procesory, popř. použitím assembleru se dají dělat divy. Zdenek
----- Original Message ----- From: "Vaclav Peroutka (sharpemupandora.cz)" <vaclavpe[doména skryta]> To: "Konference "Počítač SHARP MZ-800 a emulátory"" <sharpemupandora.cz> Sent: Monday, November 02, 2009 8:47 AM Subject: Re: SD unikarta > > >> Mimochodem, ač se chystáte použít rychlý procesor, tipnul bych si že bude >> výhra, >> když se při současné obsluze SD karty s FAT podaří aspoň dosáhnout >> rychlosti >> běžné floppy. Každopádně, těším se na tenhle kousek HW jako malé děcko :) >> > > Zdenku, tam nejde o rychly procesor. Ale o dostatek datove RAMky, kde si > muzes udrzovat metainformace pro 4 emulovane disketove mechaniky a nejlepe > 4 SD sektory 512B (jeden pro kazdou mechaniku), se kterymi se aktualne > pracuje. At se da rozumne zapisovat. Urcite vis, ze SD karta je sekvencni > medium, abys mohl zmenit jediny bajt, musis precist a zapsat cely sektor > (ostatne, stejne jako FD). > > Samotne 4 datove sektory zaberou 2kB pameti. Metainformace pro HD disketu > taky zaberou nejake misto. A najednou jsi bez pameti. Co se tyce > rychlosti, myslim, ze by stacila dalsi Z80ka, kdyz bude mit pripojeno > aspon 8kB RAMky. Cokoli rychlejsiho je jen vyhodou. > > Ale jaka je rychlost u soucasne implementace s AVR v praxi, to musi napsat > Michal... > > V. > > PS: Jeste jednou jsem se dival na tu ATMEGu8 - zrejme by se dalo pouzit > port D, pricemz clovek prijde o interrupty. A ja je mel v me puvodni verzi > pouzite, to je pravda. SD kartu pripojit na PB2-PB5 a tech par ridicich > signalu se taky najde. Takze z tohoto pohledu by pro tu low-cost verzi > stacila ATMega8, XC9536, 74HC245. A jak psal Petr, fungovalo by to tim > zpusobem, ze z emulovaneho ROMdisku nabehne "spravce souboru" na SD karte, > uzivatel vybere MZF, zmacne CR a jedeme. V podstate jako kdyz nabootoval > CP/M a spustil program skrz MZRUN. > > ---
Dne neděle 01 Listopad 2009 23:12:11 Petr Žydek (sharpemupandora.cz) napsal(a): Ahoj,
> nezbývá než zagůglit, já to ve své tvrdohlavé snaze sehnat WD2791 > (resp. WD1773 - kusovku) dělám zrovna tak. Vypadá to na nákup z ciziny. > Sám nevím, jak to dopadne ...
to bych rád až v krajním případě.
> Sháněl ses po schematu FDD s tím, že to mé je "čitelné". > Je na Zdeňkových stránkách na: > http://mz-800.xf.cz/files/tech/MZ-FDD.bmp
Díky moc. Ctirad
Dne pondělí 02 Listopad 2009 08:47:58 Vaclav Peroutka (sharpemupandora.cz) napsal(a):
> Zdenku, tam nejde o rychly procesor. Ale o dostatek datove RAMky, kde si > muzes udrzovat metainformace pro 4 emulovane disketove mechaniky a nejlepe > 4 SD sektory 512B (jeden pro kazdou mechaniku), se kterymi se aktualne > pracuje. At se da rozumne zapisovat. Urcite vis, ze SD karta je sekvencni > medium, abys mohl zmenit jediny bajt, musis precist a zapsat cely sektor > (ostatne, stejne jako FD). > > Samotne 4 datove sektory zaberou 2kB pameti. Metainformace pro HD disketu > taky zaberou nejake misto.
Opakuji, že SDRIVE tohle všechno vyřešené má a funguje to i na té nejslabší atmeze s 1kB SRAM. A to jsem ještě zapomněl zmínit, že to umí (přes ovládací utilitku) procházet adresářovou strukturu na SD a zavádět přímo atárkovské "exe" soubory tak, že on the fly vytvoří bootovatelný obraz ATR diskety cozavede ten soubor.
> PS: Jeste jednou jsem se dival na tu ATMEGu8 - zrejme by se dalo pouzit > port D, pricemz clovek prijde o interrupty. A ja je mel v me puvodni verzi
Prosím, zapomeň(te) už na atmegu 8. To byl opravdu jen příklad.
> pouzite, to je pravda. SD kartu pripojit na PB2-PB5 a tech par ridicich > signalu se taky najde. Takze z tohoto pohledu by pro tu low-cost verzi > stacila ATMega8, XC9536, 74HC245.
Tu 74.245 bych tam dal právě proto, abych nemusel používat CPLD. Dávat tam obojí nemá smysl. Teoreticky by se dala ta atmega plácnout na sběrnici přímo. Takové projekty jsem viděl a fungovalo to, ale je to prasárna a stálo by to hodně laborování. Ctirad
Zdenku ono zase tak narocne na operace to neni ;) WD sico pro zapis sectoru zrejme vykona mnohem mene prace, nez musi ucinit AVR + SD, nicmene napr. cteni sektoru znamena v pripade WD: 1. nekolikrat se zeptat na status a cekat dokud pro nas nebudou pripravena data 2. vzit data a jit na bod 1. V tom prvnim bode jsou u WD prave ty nejvetsi casove ztraty, zatimco s AVR se Sharp nezatezuje opakovanym ctenim statusu a po jeho jednom precteni si jde rovnou pro dalsi data. Samozrejme u AVR zase roste rezie uvnitr IN a OUT instrukci, kdy je Sharp ve WAITu, coz chci pozdeji zmerit analyzatorem, protoze pri WAIT stoji i refresh a mohli by jsme prijit o obsah RAM. Jinak se musim pochlubit, ze se mi pred chvili podarilo po celodenni bitve zprovoznit prvni zapis, ktery jsem si overil v cp/m 1.3 ... soubor power.com jsem z A: zkopiroval na B: a odtud jsem jej bez problemu spustil. Ta celodenni bitva, pri ktere jsem se neustale potykal s tim, ze obcas se zapis podaril a obcas ne, uz k veceru malem vyustila do faze, kdy jsem to chtel cele vzdat ... pak se ukazalo, ze je zrejme vadna SD patice, nebo redukce a proste nekdy mi hlasi, ze je SD karta locknuta pro zapis! :) Co se tyka ostatnich dotazu na SRAM, tak prozatim se do tech 4kB vejdeme, ale je to na ukor rychlosti - tedy pro tabulky stop a sektoru se musi neustale seekovat a zapisy a cteni probihaji po jednom bajtu, misto po blocich ... Pomerne velkou rezii v rozsahu pouzite pameti ma samozrejme i to, ze bezime na FAT32, v pripade FAT16 to pada zhruba na polovinu. Michal Zdenek Adler (sharpemupandora.cz) napsal(a):
> > OK Vašku, jistě víš o čem píšeš.... Jenom mi přišlo, že když dám na > Sharpovi požadavek na přečtení sektoru a budu očekávat první bajt, tak > AVR si musí poradit s: > > 0. zpracování příkazů pro řadič, neustálé odpovídání na status > 1. čtení z FAT > 2. zvládnout strukturu DSK souboru > 3. datové přenosy SD -> SRAM, SRAM -> sběrnice Sharpa > 4. ....... a plno dalšího co ani nedomýšlím >
