[BETA] Diskuzní fórum Elektro Bastlírny

Helejte, podivejte se na ty data v bufferu jak sem cet MBR, sem si toho vsiml az ted. Nenechte se mast, ze je to vypisovany jako 16-bitovy slova, cili prehozeny MSB-LSB little endian, ale problem je, ze ty MSB jsou vsude NULA! Takze je treba zistit, jesi uz to tak blbe leze z tech SSD nebo se ten MSB ztrati nekde cestou v radici nebo jinde...

>xsc
Jo to vim ze z nakyho duvodu maj nekery prevodniky problem s ATAPI komunikaci (opticky mechaniky) zatimco ATA na nich funguje OK. Este mam stale paralelni CD-W TEAC pripojeny k SATA radici pres nakou redukci z ali a vypalovani funguje OK...

Edit: ze by to nak souviselo s pinem IOCS16# ?
Jinak vcera sem si este dones ze srotu dalsi mSATA SSD Adata 64GB a v te redukci se chova stejne jako ten Samsung.

No tak se konecne zacina vyjasnovat, uz aspon vim, proc chybi vsude MSB
After some basic diagnosis with a volt meter on the IDE cable and visual inspection of the SATA adapter boards today, I think I have an idea about why the MSB is missing. None of the SATA adapters control the -IOCS16 line, so they’re really designed for DMA transfer only where the line is ignored. RiscPC doesn’t support DMA, only PIO, so it’s expecting -IOCS16 to be pulled low if 16bit data is presented on the bus.
Ted uz jen zbyva vyresit, jak ten IOCS16 vygenerovat, aby byl radic spokojeny, resp. zjistit, jak je to na strane radice zadratovane, jestli by nestacilo ten pin na strane disku jesnoduse uzemnit. Pri nejhorsim to musi jit nak vyrobit z RD/WR signalu ORem..

EDIT:
no tak je to jak sem si myslel, Transcend ani ta mSATA redukce nemaji signal IOCS16# (pin 32) vubec zapojeny. Na obou IDE radicich je ten signal proroutovany z IDE konektoru primo na ISA sbernici IOCS16# (pin D2). Kdyz koukam na casovaci diagram, tak ten IOCS16# nebude uplne jednoduche vyrobit. Signaly DIOW#/DIOR# jsou na 1 radici taky primo propojene na ISA IOW#/IOR#, takze primo je sloucit do IOCS16# nemuzu...

Ne, tak spis bych mel vyuzit signaly CS0# a CS1# a z nich udelat AND. Protoze je IOCS16# open collector, tak by to melo jit sloucit 2 diodama se spolecnou anodou na IOCS16# a katodama na kazdy CSx#. Tedy kdyz se na kteremkoliv z nich objevi 0, tak proud protece diodou do zeme a stahne to, to by mohlo fachat. Akorat to jeste komplikuje fakt, ze pri DMA prenosu se ten IOCS16# nesmi generovat...

Hm, tak to nefunguje, navic na tech CS0# a CS1# furt neco lita i kdyz se na disk nepristupuje.

Aha, tak to tak jednoduse nepujde, ten 16-bit pristup je jen k datovemu registru, takze musim postavit plny dekoder z 5 signalu CS1#, CS0#, A2:0 a generovat IOCS16# jen pri kombinaci 0,1,0,0,0 .

rnbw píše:(má len 16 kanálov).
http://sigrok.org/wiki/Lcsoft_Mini_Board

RayeR píše:aspoň 24 by to chtělo...

Nešlo by využít kromě portů PB a PD (neboli FD) využít také PA ???
Tak bychom byli na 24 kanálech.
(A možná by se daly použít i CTL/FLAG.)

Nie, neslo. Podporuje to len 16-bitove automaticke prenosy medzi FIFO a USB (obchadzaju jadro 8051, ktore na to nema vykon).

ATA dvojka (03/1996) tvrdí toto:

5.2.11 IOCS16- (Device 16-bit I/O)
During PIO transfer modes 0, 1 or 2, IOCS16- indicates to the host system that the 16-bit data port has been
addressed and that the device is prepared to send or receive a 16-bit data word. This shall be an open
collector output.
- When transferring in any PIO mode and accessing any register except the data port, transfers shall
be 8-bit using DD0-7;
- When transferring in PIO modes 0, 1 or 2, if IOCS16- is not asserted, transfers shall be 8-bit using
DD0-7;
- When transferring in PIO modes 0, 1 or 2, if IOCS16- is asserted, transfers shall be 16-bit using
DD0-15;
- When transferring in PIO modes 3 or 4, IOCS16- shall not be used by the host, and all transfers
shall be 16-bit using DD0-15, except for bytes beyond the 512th byte for READ LONG and WRITE
LONG commands which shall be 8-bit using DD0-7;
- When transferring in DMA mode, the host shall use a 16-bit DMA channel and IOCS16- shall not
be asserted.

Globálně vzato, IOCS16 non není tak nepostradatelný. Vysílá ho periferie (disk), a to jen v PIO 0..2, na datovém portu 01F0h. Např. v případě našeho milého osmibiťáčku MZ-800 jsme ho v návrhu rozhraní úspěšně ignorovali a komunikace s diskem fungovala. Pravdou ale je, že IO interfejsing MZ800 s CPU Z80 je oproti PC pomalý -> 1/(17,734476×10^6)/5) = 282ns (jedna perioda CPU CLK) a IO instrukce (OTIR) má 21T => 5.92µs. A PIO 0 přenáší datové slovo každých 600ns.

Pokud by se měl vytvářet IOCS16 non, udělal bych to takto: Je-li DA(2,1,0)=000b a CS0=LOW a DIOW=LOW, potom IOCS16=LOW (jen příklad, pro zápis). Zkusit ho připojit ke GND trvale bych taky zkusil, nemělo by se nic stát (signál má být open collector).

Dokumentace na www.t13.org je dostupná jen registrovaným, já jich několik postahoval před mnoha lety, kdy to bylo ještě volně k dispozici.

IOCS16# je signal ISA zbernice, ktorym zariadenie hovori systemu, ze port je 16-bitovy. Ked je neaktivny, tak 16-bitovy pristup (inw/outw) sa skonvertuje na dva 8-bitove.

Pri vyssich PIO modoch je vynechany, pretoze tam uz musi byt IDE radic skutocny a nie len pripojenie na ISA zbernicu.

Pripojit IOCS16# na GND je blbost a nefunguje, to by ovlivnilo uplne vsechny prenosy na ISA sbernici, nejen mezi diskem. Pisu ze je to na radici propojene primo z disku na ISA. Musim zkusit spachat nakej hradlovej dekoder, neska to uz asi nedam, sem nakej tuhej. Jen me matlo, ze na osciloskopu sem videl na CS1,0 chodily porad nake jehly do log 0 asi 50ns s pomerne dlouhou periodou opakovani, aniz by probihala naka viditelna diskova aktivita. Ty signaly sou prece dekodovany podle adresy portu 17x/1fx, takze jina aktivita z ISA by tam bejt videt nemela. Jesi se to tam indukovalo nejak parazitne...?

Pokud u toho Sharpu komunikujete ciste 8-bitove a disk to umi (CF karty snad vsechny), tak no problem, pak IOCS16# nepotrebujes.

Podle tehle tabulky bych mel dekodovat tuhle kombinaci.
Melo by to jit udelat z 1x 4-vstup NOR a 1x 2-vstup NAND s O.K. Ten NOR 7429/74HC4002 tu zrovna nemam...

edit: POZOR, V TEHLE TABULCE JE SPATNE CS0, CS1, MA BYT PROHOZENE!

...Pripojit IOCS16# na GND je blbost a nefunguje...

Tak to se kaju, já ty popisy nestudoval řadu let. Nechal jsem se unést, anžto jsem letmo nahlédl do ATA-2 (mám staženo a neztraceno) a neuvědomil jsem si, že to může být nadrátováno bez oddělení (zaměřil jsem se na stranu disku, ne počítače). Ale tu slovní logickou rovnici jsem spáchal stejně, jako je to v onom žlutě zvýrazněním místě v tabulce ideregs.

Pokud u toho Sharpu komunikujete ciste 8-bitove a disk to umi (CF karty snad vsechny), tak no problem...

Původní studie připojení ATA disku k MZ-800 tak byla skutečně vymyšlená, ale protože v tom případě nefungovalo ono "IDENTIFY DEVICE (OPCODE - ECh)" začal jsem se v původním řešení brněnského sharpisty Zdeňka Adlera vrtat a přišel s řešením se dvěma registry 74F652, které dva zápisy Z80kové instrukce OUT odbaví jako přenos jednoho šestnáctibitového slova na straně disku (analogicky i pro čtení). Na IO adrese, která odpovídá datovému portu u PC (01F0h) se děje výše zmíněný "převod", ostatní ATA porty obslouží Sharp běžnou osmibitovou instrukcí OUT (IN). A protože Sharp nemá sloty ISA (přestože rozložení signálů na MZ slotech je skoro na úrovni PC-XT) IOCS16 na straně ATA konektoru visí v luftě, jako spousta jiných. Dokonce jsem našel článek, ve kterém je o mně zmínka. Jenže pak nastoupil projekt Unicard a po něm Bohoušův Unicard 3b (sharpista původem od Sokolova) a rázem bylo po nadšeneckém hardwéraření. Unicard 3b je MCU STM na desce, které softwarově emuluje nativní sharpí FDC (a mnoho dalšího) a jako média - virtuální diskety, používá soubory na kartě mikro SD.

Jo, Bohouse sem chvili zazil jako kolegu v praci, nez sem z tama sel d pyce, je to takovej STM32 God

Tak jsem zvitezil nad hmotou!
Spachal sem ten dekoder ze 2 74-hradylek a nefungovalo to. Hodinu si lamu hlavu proc, picham do toho osciloskopem proc ze se IOCS16# negeneruje a nakonec zistuju, ze ty mrtky maj tu tabulku registru na webu spatne, ze je tam prohozena polarita CS0# a CS1#, takze spravne se ma dekodovat kdyz CS0#=0, CS1#=1, DA2:0=0. Takze prehazuju 2 dratky na nepajku a uz to frci, ctu 16-bitove, identify vypada konecne jak ma, tak reset a XTIDE se chytilo a normalne boot. Takze kecy prdy ze nemuze moderni SSDcko behat na 386 ci klidne XTcku...
Vyrobim na to nakou malou desticku, ktera se zezadu radice pripaji na IDE konektor a jumperem se generovany IOCS16# pripoji na pin 32.

Dobra praca. Mozes to dat vyrobit do Ciny a predavat.

Tak to se kaju podruhé...

Pokud by se měl vytvářet IOCS16 non, udělal bych to takto: Je-li DA(2,1,0)=000b a CS0=LOW a DIOW=LOW, potom IOCS16=LOW (jen příklad, pro zápis).

Slovní "rovnici" mám dobře, ale nenapadlo mě shlédnout tu tabulku ideregs pořádně. Podvědomě jsem čekal sloupce v pořadí CS0, CS1, DA2, DA1, DA0. A ony jsou názvy signálů nad prvními dvěma sloupečky prohozené, to jsou věci.

Ale je fakt, že staré přísloví praví, že "pod svícnem je tma". A že se nejjednodušší (a zřejmé) chyby často špatně hledají...

A že ohledně informací z internetu platí věta - "důvěřuj, ale prověřuj".

No me ze zacatku matlo, ze na tom IOCS16 byl neustale nejaky provoz (ze sbernice PC) a taktez na tech CS0,1 se taky furt neco delo, takze se to pak neda jednoduse zasynchronizovat kdyz si poslu read sector. Nevim jesi BIOS neustale kontroluje nejaky status registr nebo kdo...

Jen dodam, ze ten IOCS16 dekoder neresi problem, proc s timle radicem mSATA SSD tuhnou, to je zas naka jina nekompatabilita a s timhle to nesouvisi. Na to druhem radici urcite pojedou, ale ted se mi to nechce predratovavat, az budu mit final PCB...

Tak jsem tam nainstaloval na ten Transcend SSD Win95 OSR 2 (cca 45 minut) a jsem docela prijemne prekvapen, jak to hladce bezi, SSD proti plotnaku udela proste radove vetsi rozdil nez nekolikanasobne rychlejsi CPUcko...
http://rayer.g6.cz/hardware/retropc2.htm#XTIDE-SSD