OldComp.cz

dík za analýzu
disketa je vytvořena ve stejné mechanice a zpět ji též přečtu ve stejné, ale musím použít jiný program, ne ulticopy -tam jede vždy s chybama (4-7 chyb náhodně)
+ pokud disketu vytvořenou v ní dám do jiné, tak je 100% čitelná bez chyby a i v ulticopy

Když do ty disketovky dám jinou mechaniku, která čte naprosto vše, tak to začne být citlivý na diskety. -proto jdu po SW, něco je na hraně
má cenu v tom asm ještě něco hledat?¨

příští víkend budu mít ještě další mechaniku, tak udělám další pokusy.

_________________
C64C 2x, C64C s S-Video, C64 MK2 reloaded, floppy 1541-II 3x, Commodore monitor 1084, MPS1250, 1541 ultimate II+, FCIII, SD2IEC, XU1541
*** 8bit lives matter ***

Napadla mě ještě jedna základní věc,aby jsme vyloučily další věci, podívej se na hlavu, jestli není nějak znečištěná nebo poškozená a pro jistotu ji vyčisti isopropanolem.

_________________
JMP $FCE2

C64, C128DCR, IDE64, SuperCPU64, 1541 Ultimate-II, MMC Replay, FC3, REU 2MB, Geroram512, NeoRAM 2MB, RR-Net, SilverSurfer, Wiznet64 , 1541-II,1571,1581,Oceanic

hlava je čistá (čistil jsem jen slivovicí a uchošťouchem),
mrkni na začátek vlákna, čte na 100% podle diagnostiky v jiném programu.

napadá mě jestli to není pohybem krokového motoru -nějakým časováním, jestli není někde v mezistopě -třeba jen o jeden tik krokáče
+nějaká data v mezistopách jsou a já nemám 100% čistou disketu, kde by byl čistě jen jeden zápis

že bych zkusil udělat nějaký mechanický porovnání, kde jezdí ulticopy a kde jiný soft abych vyloučil toto,
pokud bude možno jeden tik vůbec porovnat

porovnáním image D64 získaným z ulticopy s originálem má opravdu chyby -takže ty mínus na obrazovce sedí = blbě čte

nahrál bych i nějaký video, pokud by se dalo vysledovat, jak dlouho je na stopě, jestli se projevuje 100 pokusů o čtení
ale něco mi nesedí - když se disketa točí 300 ot/min = 5 ot/s, tak při chybném čtení a 100 pokusech (viz rutina) to musí minimálně 20s čekat v jedné stopě
těch 100 pokusů je cekově na jeden sektor, nebo stopu? poku na sektor, tak by to mělo být i víc sekund, ale já mám celou disketu cca kolem minuty

_________________
C64C 2x, C64C s S-Video, C64 MK2 reloaded, floppy 1541-II 3x, Commodore monitor 1084, MPS1250, 1541 ultimate II+, FCIII, SD2IEC, XU1541
*** 8bit lives matter ***

Nekoukal jsem,jeslti Ulticopy přenastavuje VIA registr na jemnější chod serva.Pokud je servo už vyběhané,nebo je velká v mechanismu mezi servem a hlavou, může to mít též za následek,že se hlava posune místo o celou stopu nějak o půl a něco.



Jeden sektor tvoří Header block a Data block.Na začátku Header blocku a Data blocku jsou sync marky.Mezi header blockem a data blockem je ještě header gap složený z osmi $55 bajtů, to je čitelné i z té rutiny.CBM DOS nikdy nečtě tyto bajty.Sektory jsou oddělené mezi ssebou ještě jedním tail gapem,která je dlouhá 4-12 bajtů.
V předchozím vláknu jsem napsal chybu, timeout na sync je jen 20ms,ale na načtění header block má CBM DOS 90 pokusů, v případě Ulticopy 99x.Další pokus o načtení header blocku se děje stylem - načíst opět sync a pokusit se opět načíst header block a to jest 90x nebo 99x v případě Ulticopy.

_________________
JMP $FCE2

C64, C128DCR, IDE64, SuperCPU64, 1541 Ultimate-II, MMC Replay, FC3, REU 2MB, Geroram512, NeoRAM 2MB, RR-Net, SilverSurfer, Wiznet64 , 1541-II,1571,1581,Oceanic

Hrubě cca vím co se kde v ulticopy dělá, už do toho čumím několik hodin + porovnávám s IO mapou VIA.
Chybu zatím nevidím žádnou.

Co vlastně chci -pokud je někde chyba v ulticopy, najít ji a reportovat -> nový opravený FW, možná to pomůže více lidem, chyby s ulticopy jsem viděl i jinde, ale nikdo se tím nezaobíral.

Možná mám pouze špatnou mechaniku/hlavu, ale to mi zatím nesedí, protože mi to jinde jede na 100% + demo BIBA3 mi jede pouze na této mechanice komplet bezchybně

Cosmosi, pokud máš nějaké nápady co přesně zkusit, tak sem s nima.
ta moje teorie, že je hlava někde mimo stopu mi úplně nesedí s tím, že není nikdy víc chyb v sektoru, max 1.
spíš mi to připadá, že není vypnuté nějaké přerušení SEI / CLI -ale zase to jde v jiné mechanice, divný
mám už další mechaniku (celkem 3), tak to můžu různě kombinovat elektronika/mechanika/jiná disketa/nahraný obraz v různých mechanikách
-nechci přehazovat hlavičky ani krokový motor, ono to ani nejde, má to jiné uchycení + jiné šasi
na mechanice s možností regulací otáček můžu zkusit přidat/ubrat a zjistit vliv jak se to bude chovat s ulticopy

s vůlí hlavy - při čtení jsem zkoušel přidržovat pohyb hlavy, je to pevný jak beton, nikde žádná vůle a pohyb je fakt silný, jak je motor pod proudem, nedá se nikam posunout, musel bych hodně zabrat
-asi nahraju nějaký videa, pro představu, ale až o víkendu, jsem pracovně mimo

_________________
C64C 2x, C64C s S-Video, C64 MK2 reloaded, floppy 1541-II 3x, Commodore monitor 1084, MPS1250, 1541 ultimate II+, FCIII, SD2IEC, XU1541
*** 8bit lives matter ***

tak jsem dostal odpověď od autora a ulticopy momentálně neřeší opakování při chybě čtení
chybu pouze finálně vyhodnocuje ultimate, kdy udělá kontrolní součet.

opakování je jen pro datablok ve stopě - jestli je načten nebo ne.
tím se vše vysvětlilo


má též podezření, že to může dělat i samotný přenos po IEC. Bohužel nemám dvoukanálový osciloskop na ověření
viz zde
Do you have an oscilloscope? If so, you could measure the SRQ line, and
observe its timing against DATA and CLOCK. The SRQ line shows when the data
is sampled, at least, when the first two bits and the second two bits are
sampled of each byte. This should be exactly in the middle of the bit in
the beginning of each transfer block of 128 bytes, but it may drift apart
during the transfer of a block. If the drift causes the sampling moment to
be too close to the transitions of DATA and CLOCK, the clock frequency
offset is just too much and the transfer blocks need to be cut into smaller
chunks.

_________________
C64C 2x, C64C s S-Video, C64 MK2 reloaded, floppy 1541-II 3x, Commodore monitor 1084, MPS1250, 1541 ultimate II+, FCIII, SD2IEC, XU1541
*** 8bit lives matter ***

Dopoledne jsem se bavil s Gideonem ohledně toho problému, protože na FB někdo postoval stejný problém.
Příčina je ppm deviace v krystalu v 1541.Pokud jeden je rychlejší, druhej pomalejší,celé se to zrychluje.Proto jeden drive je OK a druhej může reportovat sem tam chyby, Ulticopy má časování trochu nafest.Slíbil,že tu rutinu trochu zreviduje ,ale nevím kdy, dnes opravoval v U64 komatabilitu pro IDE64.

_________________
JMP $FCE2

C64, C128DCR, IDE64, SuperCPU64, 1541 Ultimate-II, MMC Replay, FC3, REU 2MB, Geroram512, NeoRAM 2MB, RR-Net, SilverSurfer, Wiznet64 , 1541-II,1571,1581,Oceanic

udělal jsem testy s další novou disketovkou a výsledek je jasný, chybu způsobuje při čtení hlava,
mám 3 disketovky, každá s jinou hlavou a mechanikou. Přeházoval jsem mezi sebou mechaniku a elektroniku
a jedna mechanika zlobí, 1-7 náhodných chyb na disketu
elektronika na to nemá vliv,

projevuje se ale pouze v ulticopy, protože nedělá kontrolní součet a opakování čtení.

zkoušel jsem i upravit rychlost otáčení 300 +- 2 otáčky -nemá vliv, ulticopy přečte

měl by být nový FW s opakováním čtení

co se dá udělat s hlavou, aby četla na 100% i v ulticopy
čistá je, nastavení nuly není třeba (disketu jsem zapsal na ní)

_________________
C64C 2x, C64C s S-Video, C64 MK2 reloaded, floppy 1541-II 3x, Commodore monitor 1084, MPS1250, 1541 ultimate II+, FCIII, SD2IEC, XU1541
*** 8bit lives matter ***

Ulticopy nedělá žádný retry při čtení, protože tím by se rozhodilo komplet časování,které má udělané aktuálně natvrdo.
Pokud ten drive má pochybnou hlavu, může posloužit na debug,ale asi bych ji nezahrnul v sestavě jako spolehlivou.
Vem ohmetr a zkus změřit všechny hlavy, jaké mají odchylky v Ohmech.

_________________
JMP $FCE2

C64, C128DCR, IDE64, SuperCPU64, 1541 Ultimate-II, MMC Replay, FC3, REU 2MB, Geroram512, NeoRAM 2MB, RR-Net, SilverSurfer, Wiznet64 , 1541-II,1571,1581,Oceanic