Původní podoba příspěvku
Surová data tak, jak byla v roce 2013 stažena z Pandory (HTML zdroj bez úprav, osobní e-mailové adresy jsou maskované).
<!--------------------------------------------------------------> <table width="100%"><tr><td align="left" valign="middle"><B>Unikarta s SD pro Sharpa:</B></td><td align=right valign="middle"></td></tr></table><BR><pre>Ok, takze kdyz uz se to takhle predcasne proflaklo, tak zkusim popsat na cem <img src="BODY_IMAGES_WRAP_GIF"> tedy s Vaskem delame a jake by mely byt cile projektu: Univerzalni karta pripojena do Sharpa by mela obsahovat CPLD, SRAM, AVR <img src="BODY_IMAGES_WRAP_GIF">(momentalne ATmega64, ale asi to zvladne i ATmega16), SD kartu, MAX232, pripadne <img src="BODY_IMAGES_WRAP_GIF">jeste nejaky RTC - ten jsem k tomu jeste nepripojil. V tomto zapojeni tedy nyni mame zprovozneno nasledujici: RAMdisk: ======== V podstate muze byt libovolne velky, ale rostou s tim naroky na CPLD. Posledni <img src="BODY_IMAGES_WRAP_GIF">funkcni varianta s 512KB SRAM vyzadovala minimalne XC9572 ... nicmene tohle <img src="BODY_IMAGES_WRAP_GIF">hradlove pole jsem vcera nejakym zpusobem odbouchnul a tak jsem dnes pripajel <img src="BODY_IMAGES_WRAP_GIF">XC95144 a dale budu experimentovat s nim, takze pak zkusim na soucasnou SRAM <img src="BODY_IMAGES_WRAP_GIF">pripajet treba jeste dalsich 3x512K a ziskame tim 2MB RAMdisk. SD repozitar: ========== SD karta je pripojena k AVR ATmega64 s R/W podporou FAT32. Momentalne velmi <img src="BODY_IMAGES_WRAP_GIF">jednoduse navrzene ovladani, kdy jsem port 0x50 vyclenil pro prikazy a port 0x51 <img src="BODY_IMAGES_WRAP_GIF">pro prenos dat. Nechtel jsem to jeste zatezovat zadnymi komunikacnimi standardy, takze prozatim <img src="BODY_IMAGES_WRAP_GIF">je mozne jen to, ze si Sharp rekne o nejaky MZF soubor a dostane ho. Casem predpokladam nejaky shell k prochazeni FAT32 napr. cp/m, hack BASICu, tak <img src="BODY_IMAGES_WRAP_GIF">aby CMT operace pracovaly s MZF na SD karte. ROMdisc BOOT: ============= Karta se na portech 0xf8 - 0xfa chova i jako RAM disk ze ktereho se Sharp snazi <img src="BODY_IMAGES_WRAP_GIF">nabootovat, pricemz je mu z AVR podstrcen cca 100 bajtovy loader, ktery si z SD <img src="BODY_IMAGES_WRAP_GIF">natahne soubor boot.mzf a spusti jej. FDC emulator: ============ Nejedna se o striktni emulaci WD279x. AVR si z SD otevre DSK soubor ve kterem <img src="BODY_IMAGES_WRAP_GIF">dle pozadavku Sharpa na radic seekuje. Status registr emulovaneho FDC jsem <img src="BODY_IMAGES_WRAP_GIF">prizpusoboval predevsim tomu co se v nem v programech ocekava, takze jsem si tu <img src="BODY_IMAGES_WRAP_GIF">musel disassemblovat a odkrokovat vetsinu FD rutin, ktere se na Sharpu vyskytuji <img src="BODY_IMAGES_WRAP_GIF">(diky Zdenkovu emulatoru ;) a na sve si prisel i logicky analyzer pripichnuty je <img src="BODY_IMAGES_WRAP_GIF">skutecnemu radici. Vysledkem je to, ze napr. tam kde jsem odsledoval, ze program <img src="BODY_IMAGES_WRAP_GIF">po odeslani nejakeho prikazu do FDC ocekaval nejakou dobu BUSY, pak READY, pak <img src="BODY_IMAGES_WRAP_GIF">zase BUSY + DRQ, tak proste pri prvnim dotazu na status odpovim jednim stavem a <img src="BODY_IMAGES_WRAP_GIF">pri dalsim dotazu druhym, atd. Presne tak, aby se cteci program mohl ve sve <img src="BODY_IMAGES_WRAP_GIF">cinnosti posunout k dalsimu kroku. Vyrazenim techto prodlev jsem docilil toho, <img src="BODY_IMAGES_WRAP_GIF">ze napr. cp/m z SD startuje cca o 2 sekundy rychleji, nez ze skutecne FD <img src="BODY_IMAGES_WRAP_GIF">mechaniky. Pro zajimavost: vyjimkou je tady start cp/m v1.4 a nizsich, kdy si <img src="BODY_IMAGES_WRAP_GIF">Lamacuv loader na nulte stope vyzada neexistujici sektor 0x10 a cte status <img src="BODY_IMAGES_WRAP_GIF">registr cca 5000x - pokud po tuto dobu dostane v odpovedi neco jineho, nez SEEK <img src="BODY_IMAGES_WRAP_GIF">ERR, tak se to vzdy projevi nezadoucim zpusobem... Vcera jsem hackoval cp/m v4.0 a 4.1, abych zprovoznil i podporu HD disket. V <img src="BODY_IMAGES_WRAP_GIF">pripade HD disket probiha prace s FDC trochu jinak a musel jsem AVR pripojit <img src="BODY_IMAGES_WRAP_GIF">dalsim pinem na sbernici, aby jsme mohli Sharpu posilat i pozadavky na <img src="BODY_IMAGES_WRAP_GIF">interrupt. Cteni disket jsem sice zprovoznil, nicmene neco mi po nejake dobe <img src="BODY_IMAGES_WRAP_GIF">odbouchnulo Xilinxe a mozna uz i tusim co... K emulaci prikazu pro zapisovani sektoru jsem zatim jeste nedostal, nicmene <img src="BODY_IMAGES_WRAP_GIF">prikazy pro formatovani bych asi uplne vynechal, protoze mi prijde jednodussi a <img src="BODY_IMAGES_WRAP_GIF">rychlejsi pozadat rovnou AVR o prepsani DSK image. BTW: co se tyka HD disket, tak jejich DSK image jsem stahnul na scavu ze sekce <img src="BODY_IMAGES_WRAP_GIF">UPLOAD. Chtel bych se zeptat kdo to tam uploadnul a predevsim cim ty image byly <img src="BODY_IMAGES_WRAP_GIF">vyrobeny, protoze je v nich vadna tabulka stop. Ve Zdenkovem emulatoru takovy <img src="BODY_IMAGES_WRAP_GIF">image sice funguje, protoze ten si zrejme udela analyzu souboru a vytvori si <img src="BODY_IMAGES_WRAP_GIF">vlastni tabulku stop, ovsem na AVR si tohle dovolit nemuzeme. Dalsi funkce: ========== MAX232 je prevodnik pro RS232, ktery mi momentalne slouzi jako vzdaleny shell a <img src="BODY_IMAGES_WRAP_GIF">ke sledovani debugovacich hlasek z AVR. Casem by samozrejme mohl fungovat jako <img src="BODY_IMAGES_WRAP_GIF">skutecny RS232 pro Sharpa. Zadny RTC jsem do zatim jeste nepripojil, ale bylo by faln, kdyby Sharp po <img src="BODY_IMAGES_WRAP_GIF">zapnuti vedel kolik je hodin. Zaroven by se casovy udaj z RTC pouzil jako casovy <img src="BODY_IMAGES_WRAP_GIF">atribut zmenenych, ci nove vytvarenych souboru FAT32. Uvaha do budoucna: ================= Take zvazujeme i takovou variantu teto univerzalni desky, ktera by v sobe mela i <img src="BODY_IMAGES_WRAP_GIF">scandoubler. To by uz ovsem vyzadovalo nejaky FPGA a tim padem by jsme ze <img src="BODY_IMAGES_WRAP_GIF">schematu asi vyhodili CPLD i AVR, protoze FPGA by v pohode zastal jejich funkci <img src="BODY_IMAGES_WRAP_GIF">(no, kdyz na to prijde, tak by dokazalo zastat i funkci celeho Sharpa :). Protoze by jsme s Vaskem byli moc radi, kdyby cele tohle nase snazeni neskoncilo <img src="BODY_IMAGES_WRAP_GIF">jen na stolech u nas dvou, tak chceme v brzke dobe cely projekt zverejnit treba <img src="BODY_IMAGES_WRAP_GIF">na sourceforge a budeme moc radi, kdyz se take zapojite do vyvoje. Michal </pre>