Ahoj, pisu driver do mzixu pro RRD, zabyvam se problemem jak zdetekovat na ktere pozici je nakonfigurovana flash. Prostudoval jsem navod 29F040, perfektne by se hodila funkce "Read Electronic Signature", ale jestli jsem to spravne vycetl, tak pro precteni identifikace cipu vyzaduje nastavit na A9 pinu 12V, umi to RRD? Jestli ne, tak asi nezbude nez zkusit nekam neco ve flashce prepsat (pomoci programovaciho algoritmu pro flashku) a pak se podivat jestli se to tam fakt zapsalo. A kdyz tak pak vratit zpatky co tam bylo. Nejake jine tipy? Fuzzy
Celé vlákno · 27 zpráv
Re: RRD - detekce flash
VELESOFT (SPRINTER) SHARP MZ-800
12 na pinu A9 temer nikdo nepouziva a podle me to neumi ani RRD. Pak je jedina sance a to vyzkozset flashovat ruznym zpusobem, dokud se ti nepovede rom naflashnout spravne. Nebo se tomu jednoduse vyhnout a vyresit to jinak. Rekneme si, ze na nejakem pevnem miste v romce bude umisteny text s oznacenim typu dane pameti (treba AM29F040). No a flasher si uz priste typ vycte sam a netreba nic testovat. Pri prvnim flashovani by si mel uzivatel zvolit v menu o jaky typ flash eprom jde a podle toho flasher vybere vhodnou rutinu a soucasne do rom na dane misto zapise i jeji typ. VELESOFT
Zobrazit citovaný text (28 řádků)
----- Original Message ----- From: "Fuzzy (sharpemupandora.cz)" <martin.matyas[doména skryta]> To: "Konference "Počítač SHARP MZ-800 a emulátory"" <sharpemupandora.cz> Sent: Tuesday, March 13, 2012 5:15 PM Subject: RRD - detekce flash > > Ahoj, > > pisu driver do mzixu pro RRD, zabyvam se problemem jak zdetekovat na > ktere pozici je nakonfigurovana flash. > Prostudoval jsem navod 29F040, perfektne by se hodila funkce "Read > Electronic Signature", ale jestli jsem > to spravne vycetl, tak pro precteni identifikace cipu vyzaduje > nastavit na A9 pinu 12V, umi to RRD? > > Jestli ne, tak asi nezbude nez zkusit nekam neco ve flashce prepsat > (pomoci programovaciho algoritmu pro flashku) > a pak se podivat jestli se to tam fakt zapsalo. A kdyz tak pak vratit > zpatky co tam bylo. > > Nejake jine tipy? > > Fuzzy > > ---
Re: RRD - detekce flash
Radek Suk SHARP MZ-800
Ahoj Martine Co se tyce cteni jakou flash mas na desce tak se da pripade pouzit napr. dokument http://www.gme.cz/_dokumentace/dokumenty/415/415-023/dsh.415-023.1.pdf a tam na strane 13 je kombinace na vycteni dat (3xwrite 1xread): 555 AA 2AA 55 555 90 X00 01 - cteni vyrobce 555 AA 2AA 55 555 90 X01 A4 - cteni typu vyrobku u vyrobce Nutno rici ze jsem to nezkousel ale melo by to chodit, videl jsem to u vsech vyrobcu. Martine u kazdeho vyrobce ti to vrati jinou hodnotu. Samozrejme muzes menit jeden bajt ale nasledne musis zpet smazat cely sektor a to je napr. u teto pameti 64KB dat. Spise by bylo vhodneji na zacatku flash aby byla nejaka znacka a tu hledat a podle toho nastavit system. Jinak porty jsou stejne jako u u zalohovane ramdisku a take typu Pezik a tak vim ze kdyz jsem neco pred 20 lety programoval tak nebylo jednoduche to udelat tak aby jsi pri detekci neznicil data na druhem typu ramdisku. Kdyz budes uvazovat jen o RRD a vynechas PEZIK tak jen musis zajistit aby jsi zapisem nenicil data v ramdisku (RAM). Musi se rici co se ma hledat - zda jen typ disku (zalohovany ramdisk,PEZIK,FLASH) a pripadne take velikost jedne banky, ktera bohuzel muze byt pro kazdou banku jina. Zde by byla vyhodna ta eeprom s ID typu karty a nastaveni jak drive psal Petr Zydek. Urcite se rad podivam na vysledek tve prace. Radek Dne 13.3.2012 17:15, Fuzzy (sharpemupandora.cz) napsal(a):
Zobrazit citovaný text (21 řádků)
> Ahoj, > > pisu driver do mzixu pro RRD, zabyvam se problemem jak zdetekovat na > ktere pozici je nakonfigurovana flash. > Prostudoval jsem navod 29F040, perfektne by se hodila funkce "Read > Electronic Signature", ale jestli jsem > to spravne vycetl, tak pro precteni identifikace cipu vyzaduje > nastavit na A9 pinu 12V, umi to RRD? > > Jestli ne, tak asi nezbude nez zkusit nekam neco ve flashce prepsat > (pomoci programovaciho algoritmu pro flashku) > a pak se podivat jestli se to tam fakt zapsalo. A kdyz tak pak vratit > zpatky co tam bylo. > > Nejake jine tipy? > > Fuzzy > > --- > >
Re: RRD - detekce flash
Fuzzy SHARP MZ-800
Ahoj, podle toho AMD service manualu by to melo jit i bez 12V na A9, asi to chce vyzkouset, uvidim. Obecne, detekce by mela zjistit o RD co nejvic, aby se nic nemuselo konfigurovat rucne. Tj. - typ RD: RAM, SRAM, ROM, Flash EPROM (+ typ chipu), PEZIK - mapa stranek a jejich prepinani - melo by byt umozneno pouzivat ruzne typy RD soucasne (kde nejsou v konfliktu) - na velikosti a slozitosti detekcniho kodu nezalezi, po detekci nakonfiguruje system a jadro ho zahodi. aktualne muj driver umi zdetekovat velikost a umisteni SRAM casti RRD (aniz by znicil data) a automaticky sestavit mapu strankovani. Takze uz pouzivam 1.5 MB RD. Ohledne PEZIKa nemam moc jasno - jak se strankuje? Tohle se mi nikde nepodarilo dohledat. Fuzzy 2012/3/13 Radek Suk (sharpemupandora.cz) <suk[doména skryta]>:
Zobrazit citovaný text (61 řádků)
> > Ahoj Martine > > Co se tyce cteni jakou flash mas na desce tak se da pripade pouzit napr. > dokument > http://www.gme.cz/_dokumentace/dokumenty/415/415-023/dsh.415-023.1.pdf > a tam na strane 13 je kombinace na vycteni dat (3xwrite 1xread): > 555 AA 2AA 55 555 90 X00 01 - cteni vyrobce > 555 AA 2AA 55 555 90 X01 A4 - cteni typu vyrobku u vyrobce > Nutno rici ze jsem to nezkousel ale melo by to chodit, videl jsem to u vsech > vyrobcu. > Martine u kazdeho vyrobce ti to vrati jinou hodnotu. > > Samozrejme muzes menit jeden bajt ale nasledne musis zpet smazat cely sektor > a to je napr. u teto pameti 64KB dat. > Spise by bylo vhodneji na zacatku flash aby byla nejaka znacka a tu hledat a > podle toho nastavit system. > > Jinak porty jsou stejne jako u u zalohovane ramdisku a take typu Pezik a tak > vim ze kdyz jsem neco pred 20 lety programoval tak > nebylo jednoduche to udelat tak aby jsi pri detekci neznicil data na druhem > typu ramdisku. > Kdyz budes uvazovat jen o RRD a vynechas PEZIK tak jen musis zajistit aby > jsi zapisem nenicil data v ramdisku (RAM). > Musi se rici co se ma hledat - zda jen typ disku (zalohovany > ramdisk,PEZIK,FLASH) a pripadne take velikost jedne banky, ktera bohuzel > muze byt pro kazdou banku jina. > Zde by byla vyhodna ta eeprom s ID typu karty a nastaveni jak drive psal > Petr Zydek. > > Urcite se rad podivam na vysledek tve prace. > > Radek > > > Dne 13.3.2012 17:15, Fuzzy (sharpemupandora.cz) napsal(a): > >> Ahoj, >> >> pisu driver do mzixu pro RRD, zabyvam se problemem jak zdetekovat na >> ktere pozici je nakonfigurovana flash. >> Prostudoval jsem navod 29F040, perfektne by se hodila funkce "Read >> Electronic Signature", ale jestli jsem >> to spravne vycetl, tak pro precteni identifikace cipu vyzaduje >> nastavit na A9 pinu 12V, umi to RRD? >> >> Jestli ne, tak asi nezbude nez zkusit nekam neco ve flashce prepsat >> (pomoci programovaciho algoritmu pro flashku) >> a pak se podivat jestli se to tam fakt zapsalo. A kdyz tak pak vratit >> zpatky co tam bylo. >> >> Nejake jine tipy? >> >> Fuzzy >> >> --- >> >> > > > ---
Re: RRD - detekce flash
Michal Hučík SHARP MZ-800
Ahoj Martine, pokud vim, tak PEZIK v podstate nijak explicitne nestrankuje. Podle zvoleneho portu oslovujes rovnou konkretni stranky - tady jsou moje VHDL modely ramdisku - alespon takhle mi s nimi fungovala cp/m, tak jsem dal neresil, zda v tom neni jeste nejaka dalsi zaludnost (realny PEZIK jsem nikdy nevidel) http://duna.ordoz.com/ramdisc/ Michal Dne 13.3.2012 21:22, Fuzzy (sharpemupandora.cz) napsal(a):
Zobrazit citovaný text (6 řádků)
> > Ohledne PEZIKa nemam moc jasno - jak se strankuje? Tohle se mi nikde > nepodarilo dohledat. > > Fuzzy >
Re: RRD - prace s PEZIKem
Michal Hučík SHARP MZ-800
Preposilam dokument, ktery mi kdysi k ramdiskum poslal Zdenek.
Přílohy
-
PEZIK.TXTtext/plain · 1 kB
Re: RRD - detekce flash
Radek Suk SHARP MZ-800
Posilam cast kodu co pouzivam ja:
nezrd: ld c,a
pop af ; v Cy- je zda se zapisuje nebo cte
ld a,80h
jr c,nezwr
nezrd1: ld b,e
in b,(c)
ld b,d
ini
inc e
dec a
jr nz,nezrd1
jr rdok
nezwr: inc d
nezwr1: ld b,e
in b,(c)
ld b,d
outi
inc e
dec a
jr nz,nezwr1
jr rdok
Jinak dulezita informace je ze pri 256KB ramdisku se pouziva ec-ef a az
pri 512KB pak jeste e8-eb. 64KB ramdisk pouziva jen port ec.
Vlastni komunikace probiha tak ze na a8-a15 je vzdy adresa a to nejdrive
spodni a v dalsim intrukci horni.
Proto logicky je prvni instrukce in a druha in/out.
Data se prenaseji na datove sbernici.
Schema je http://www.scav.cz/data/MZ-800/Vyroba_Popis_Ramdisk_Pezik.jpg
Ja osobne jsem zmenil port z e8 na 68h abych mohl mit v Sharpovi oba
typy ramdisku soucasne a tim dosahnul 1,5MB Ram - s tim pocita i MZ DOS
v1.0.
Radek
Dne 13.3.2012 21:22, Fuzzy (sharpemupandora.cz) napsal(a):
Zobrazit citovaný text (87 řádků)
> Ahoj, > > podle toho AMD service manualu by to melo jit i bez 12V na A9, asi to > chce vyzkouset, uvidim. > > Obecne, detekce by mela zjistit o RD co nejvic, aby se nic nemuselo > konfigurovat rucne. Tj. > - typ RD: RAM, SRAM, ROM, Flash EPROM (+ typ chipu), PEZIK > - mapa stranek a jejich prepinani > - melo by byt umozneno pouzivat ruzne typy RD soucasne (kde nejsou v konfliktu) > - na velikosti a slozitosti detekcniho kodu nezalezi, po detekci > nakonfiguruje system a jadro ho zahodi. > > aktualne muj driver umi zdetekovat velikost a umisteni SRAM casti RRD > (aniz by znicil data) a automaticky sestavit mapu strankovani. > Takze uz pouzivam 1.5 MB RD. > > Ohledne PEZIKa nemam moc jasno - jak se strankuje? Tohle se mi nikde > nepodarilo dohledat. > > Fuzzy > > > 2012/3/13 Radek Suk (sharpemupandora.cz)<suk[doména skryta]>: >> Ahoj Martine >> >> Co se tyce cteni jakou flash mas na desce tak se da pripade pouzit napr. >> dokument >> http://www.gme.cz/_dokumentace/dokumenty/415/415-023/dsh.415-023.1.pdf >> a tam na strane 13 je kombinace na vycteni dat (3xwrite 1xread): >> 555 AA 2AA 55 555 90 X00 01 - cteni vyrobce >> 555 AA 2AA 55 555 90 X01 A4 - cteni typu vyrobku u vyrobce >> Nutno rici ze jsem to nezkousel ale melo by to chodit, videl jsem to u vsech >> vyrobcu. >> Martine u kazdeho vyrobce ti to vrati jinou hodnotu. >> >> Samozrejme muzes menit jeden bajt ale nasledne musis zpet smazat cely sektor >> a to je napr. u teto pameti 64KB dat. >> Spise by bylo vhodneji na zacatku flash aby byla nejaka znacka a tu hledat a >> podle toho nastavit system. >> >> Jinak porty jsou stejne jako u u zalohovane ramdisku a take typu Pezik a tak >> vim ze kdyz jsem neco pred 20 lety programoval tak >> nebylo jednoduche to udelat tak aby jsi pri detekci neznicil data na druhem >> typu ramdisku. >> Kdyz budes uvazovat jen o RRD a vynechas PEZIK tak jen musis zajistit aby >> jsi zapisem nenicil data v ramdisku (RAM). >> Musi se rici co se ma hledat - zda jen typ disku (zalohovany >> ramdisk,PEZIK,FLASH) a pripadne take velikost jedne banky, ktera bohuzel >> muze byt pro kazdou banku jina. >> Zde by byla vyhodna ta eeprom s ID typu karty a nastaveni jak drive psal >> Petr Zydek. >> >> Urcite se rad podivam na vysledek tve prace. >> >> Radek >> >> >> Dne 13.3.2012 17:15, Fuzzy (sharpemupandora.cz) napsal(a): >> >>> Ahoj, >>> >>> pisu driver do mzixu pro RRD, zabyvam se problemem jak zdetekovat na >>> ktere pozici je nakonfigurovana flash. >>> Prostudoval jsem navod 29F040, perfektne by se hodila funkce "Read >>> Electronic Signature", ale jestli jsem >>> to spravne vycetl, tak pro precteni identifikace cipu vyzaduje >>> nastavit na A9 pinu 12V, umi to RRD? >>> >>> Jestli ne, tak asi nezbude nez zkusit nekam neco ve flashce prepsat >>> (pomoci programovaciho algoritmu pro flashku) >>> a pak se podivat jestli se to tam fakt zapsalo. A kdyz tak pak vratit >>> zpatky co tam bylo. >>> >>> Nejake jine tipy? >>> >>> Fuzzy >>> >>> --- >>> >>> >> >> --- > --- > >
Re: RRD - detekce flash
Vaclav Peroutka SHARP MZ-800
Zobrazit citovaný text (9 řádků)
> Ahoj, > > pisu driver do mzixu pro RRD, zabyvam se problemem jak zdetekovat na > ktere pozici je nakonfigurovana flash. > Prostudoval jsem navod 29F040, perfektne by se hodila funkce "Read > Electronic Signature", ale jestli jsem > to spravne vycetl, tak pro precteni identifikace cipu vyzaduje > nastavit na A9 pinu 12V, umi to RRD? >
Ahoj Martine, já se musím přiznat, že to tam nikde nevidím. Divám se do DS od AM29F040 a dokonce tam píšou "This device is designed to be programmed in-system with the standard system 5.0 V VCC supply. A 12.0 V VPP is not required for write or erase operations." Kde jsi tu Tvoji informaci vyčetl ? Vašek
Re: RRD - detekce flash
Radek Suk SHARP MZ-800
Ahoj Vasku, v dokumentu http://www.gme.cz/_dokumentace/dokumenty/415/415-023/dsh.415-023.1.pdf na strane 9 je oddil "Autoselect Mode". Zde je popsana identifikace pameti v externim programatoru aby se spravne vybral programovaci algoritmus. A prave pro tu identifikaci je potreba 12V. Pro vlastni cinnost, vcetne programovani staci jen 5V, jen pro tu detekci je potreba 12V a proto se to neda na Sharpovi trivialne pouzit. Radek Dne 14.3.2012 8:12, Vaclav Peroutka (sharpemupandora.cz) napsal(a):
Zobrazit citovaný text (25 řádků)
>> Ahoj, >> >> pisu driver do mzixu pro RRD, zabyvam se problemem jak zdetekovat na >> ktere pozici je nakonfigurovana flash. >> Prostudoval jsem navod 29F040, perfektne by se hodila funkce "Read >> Electronic Signature", ale jestli jsem >> to spravne vycetl, tak pro precteni identifikace cipu vyzaduje >> nastavit na A9 pinu 12V, umi to RRD? >> > Ahoj Martine, > > já se musím přiznat, že to tam nikde nevidím. Divám se do DS od AM29F040 a dokonce tam píšou > "This device is designed > to be programmed in-system with the standard system > 5.0 V VCC supply. A 12.0 V VPP is not required for > write or erase operations." > > Kde jsi tu Tvoji informaci vyčetl ? > > Vašek > > --- > >
Re: RRD - detekce flash
Vaclav Peroutka SHARP MZ-800
Zobrazit citovaný text (13 řádků)
> > Ahoj Vasku, > > v dokumentu > http://www.gme.cz/_dokumentace/dokumenty/415/415-023/dsh.415-023.1.pdf > na strane 9 je oddil "Autoselect Mode". Zde je popsana identifikace > pameti v externim programatoru aby se spravne vybral programovaci > algoritmus. A prave pro tu identifikaci je potreba 12V. Pro vlastni > cinnost, vcetne programovani staci jen 5V, jen pro tu detekci je potreba > 12V a proto se to neda na Sharpovi trivialne pouzit. > > Radek >
Aaaha, pravda pravda :) Už to vidím. Stále si musím opakovat - RTFM až do konce :-) Díky, V.
Re: RRD - detekce flash
Fuzzy SHARP MZ-800
Vasek cetl jen zacatek, Radek do prostred, a ja jsem tentokrat docetl az do konce: To access the autoselect codes in-system, the host system can issue the autoselect command via the command register, as shown in the Command Defini- tions table. This method does not require VID. See "Command Definitions" for details on using the autose- lect mode. Takze by to melo jit :-) Fuzzy 2012/3/14 Vaclav Peroutka (sharpemupandora.cz) <vaclavpe[doména skryta]>:
Zobrazit citovaný text (26 řádků)
> > >> >> Ahoj Vasku, >> >> v dokumentu >> http://www.gme.cz/_dokumentace/dokumenty/415/415-023/dsh.415-023.1.pdf na >> strane 9 je oddil "Autoselect Mode". Zde je popsana identifikace pameti v >> externim programatoru aby se spravne vybral programovaci algoritmus. A prave >> pro tu identifikaci je potreba 12V. Pro vlastni cinnost, vcetne programovani >> staci jen 5V, jen pro tu detekci je potreba 12V a proto se to neda na >> Sharpovi trivialne pouzit. >> >> Radek >> > > Aaaha, pravda pravda :) Už to vidím. Stále si musím opakovat - RTFM až do > konce :-) > > Díky, > V. > > ---
Re: RRD - detekce flash
Radek Suk SHARP MZ-800
Dnes jsem to jiz neopakoval, kdyz jsem tuto variantu popsal vcera v 7 hodin vecer, vcetne kodu co to delaji. Dnes jsem reagoval jen na tech 12V. Radek Dne 14.3.2012 11:04, Fuzzy (sharpemupandora.cz) napsal(a):
Zobrazit citovaný text (41 řádků)
> Vasek cetl jen zacatek, Radek do prostred, a ja jsem tentokrat docetl > az do konce: > > To access the autoselect codes in-system, the host > system can issue the autoselect command via the > command register, as shown in the Command Defini- > tions table. This method does not require VID. See > "Command Definitions" for details on using the autose- > lect mode. > > Takze by to melo jit :-) > > Fuzzy > > 2012/3/14 Vaclav Peroutka (sharpemupandora.cz)<vaclavpe[doména skryta]>: >> >>> Ahoj Vasku, >>> >>> v dokumentu >>> http://www.gme.cz/_dokumentace/dokumenty/415/415-023/dsh.415-023.1.pdf na >>> strane 9 je oddil "Autoselect Mode". Zde je popsana identifikace pameti v >>> externim programatoru aby se spravne vybral programovaci algoritmus. A prave >>> pro tu identifikaci je potreba 12V. Pro vlastni cinnost, vcetne programovani >>> staci jen 5V, jen pro tu detekci je potreba 12V a proto se to neda na >>> Sharpovi trivialne pouzit. >>> >>> Radek >>> >> Aaaha, pravda pravda :) Už to vidím. Stále si musím opakovat - RTFM až do >> konce :-) >> >> Díky, >> V. >> >> --- > --- > >
Re: RRD - detekce flash
Vaclav Peroutka SHARP MZ-800
Zobrazit citovaný text (12 řádků)
> Vasek cetl jen zacatek, Radek do prostred, a ja jsem tentokrat docetl > az do konce: > > To access the autoselect codes in-system, the host > system can issue the autoselect command via the > command register, as shown in the Command Defini- > tions table. This method does not require VID. See > "Command Definitions" for details on using the autose- > lect mode. > > Takze by to melo jit :-) >
Jojo, to je ta klasická sekvence 555, AAA, 555 - ta 12-tivoltová sekvence je jen rychlejší, ale to je malá věc. Už jsem se k tomu taky dopracoval :-) V.
Re: RRD - detekce flash
Fuzzy SHARP MZ-800
Ahoj, tak detekce FLASH zda se funguje dobre. V priloze je jadro MZIXu se zavadecem, zdetekuje to ramdisk. Melo by umet detekci RAM disku, FLASH + typ chipu, PEZIK (sekce "Memory card"). Bylo by super kdybyste to mohli vyzkouset na realnych RD a napsat mi zda to funguje/nefunguje pro vasi konfiguraci. Dalsi dotaz: je nejaka moznost jak zdetekovat ROM disk s ne-flash chipem? Napada me: - vyloucit moznosti ze tam je RAM nebo FLASH EPROM - projet obsah; kdyz tam je vsude 0xFF, tak tam nejspis nic namapovano neni - kdyz tam jsou bajty ruzne od 0xff, tak to ROM disk je, a to o te velikosti dokud nenarazim na stranku se samymi 0xFF Co vy na to? Fuzzy 2012/3/14 Vaclav Peroutka (sharpemupandora.cz) <vaclavpe[doména skryta]>:
Zobrazit citovaný text (21 řádků)
> > >> Vasek cetl jen zacatek, Radek do prostred, a ja jsem tentokrat docetl >> az do konce: >> >> To access the autoselect codes in-system, the host >> system can issue the autoselect command via the >> command register, as shown in the Command Defini- >> tions table. This method does not require VID. See >> "Command Definitions" for details on using the autose- >> lect mode. >> >> Takze by to melo jit :-) >> > > Jojo, to je ta klasická sekvence 555, AAA, 555 - ta 12-tivoltová sekvence je jen rychlejší, ale to je malá věc. Už jsem se k tomu taky dopracoval :-) > > V. > > ---
Přílohy
-
mzix.mzfapplication/octet-stream · 47 kB
Re: Re: RRD - detekce flash
Michal Medek SHARP MZ-800
Ahoj, taky plati, ze prvni byte ROMdisku musi byt 0xA5. Pak by se jeste dal pocitat CRC, pokud by se mel hledat platny zavadec ROMdisku. ???
Re: RRD - detekce flash
Michal Hučík SHARP MZ-800
Ahoj Martine, zda na nejakem portu visi nejake zarizeni, ktere umi vracet staticka data se pozna celkem jednoduse. instrukce IN na neobsazeny port totiz vraci vzdy stejnou hodnotu, jakou mel posledni byte na datove sbernici - v tomto pripade tedy posledni bajt instrukce IN. Test tedy muze postupne zkusit ruzne variace IN registr,(cislo) a IN registr,(C). Pokud tam je ROM disk, tak prectes pokazde stejnou hodnotu. Pokud tam neni nic, tak prectes hodnotu odpovidajici poslednimu bajtu instrukce IN. Michal Dne 19.3.2012 22:09, Fuzzy (sharpemupandora.cz) napsal(a):
Zobrazit citovaný text (42 řádků)
> Ahoj, > > tak detekce FLASH zda se funguje dobre. > V priloze je jadro MZIXu se zavadecem, zdetekuje to ramdisk. > Melo by umet detekci RAM disku, FLASH + typ chipu, PEZIK (sekce "Memory card"). > Bylo by super kdybyste to mohli vyzkouset na realnych RD a napsat mi > zda to funguje/nefunguje pro vasi konfiguraci. > > Dalsi dotaz: je nejaka moznost jak zdetekovat ROM disk s ne-flash > chipem? Napada me: > - vyloucit moznosti ze tam je RAM nebo FLASH EPROM > - projet obsah; kdyz tam je vsude 0xFF, tak tam nejspis nic namapovano neni > - kdyz tam jsou bajty ruzne od 0xff, tak to ROM disk je, a to o te > velikosti dokud nenarazim na stranku se samymi 0xFF > > Co vy na to? > > Fuzzy > > 2012/3/14 Vaclav Peroutka (sharpemupandora.cz)<vaclavpe[doména skryta]>: >> >>> Vasek cetl jen zacatek, Radek do prostred, a ja jsem tentokrat docetl >>> az do konce: >>> >>> To access the autoselect codes in-system, the host >>> system can issue the autoselect command via the >>> command register, as shown in the Command Defini- >>> tions table. This method does not require VID. See >>> "Command Definitions" for details on using the autose- >>> lect mode. >>> >>> Takze by to melo jit :-) >>> >> Jojo, to je ta klasická sekvence 555, AAA, 555 - ta 12-tivoltová sekvence je jen rychlejší, ale to je malá věc. Už jsem se k tomu taky dopracoval :-) >> >> V. >> >> --- > ---
Re: RRD - detekce flash
VELESOFT (SPRINTER) SHARP MZ-800
----- Original Message ----- From: "Michal Hučík (sharpemupandora.cz)" <ordoz[doména skryta]> To: "Konference "Počítač SHARP MZ-800 a emulátory"" <sharpemupandora.cz> Sent: Tuesday, March 20, 2012 10:40 AM Subject: Re: RRD - detekce flash > > > Ahoj Martine, > > zda na nejakem portu visi nejake zarizeni, ktere umi vracet staticka data se > pozna celkem jednoduse. instrukce IN na neobsazeny port totiz vraci vzdy > stejnou hodnotu, jakou mel posledni byte na datove sbernici - v tomto pripade > tedy posledni bajt instrukce IN. Test tedy muze postupne zkusit ruzne variace > IN registr,(cislo) a IN registr,(C). Pokud tam je ROM disk, tak prectes > pokazde stejnou hodnotu. Pokud tam neni nic, tak prectes hodnotu odpovidajici > poslednimu bajtu instrukce IN. > > Michal > No ja teda logicky predpokladam, ze pokud procesor cte neobsazeny port, mel by nacist hodnotu #FF, ktera by mela byt zajistena disky internim pull-up odporum. Nemam shema Sharpa po ruce, ale pevne verim tomu, ze tam odpory budou. Takze bych odpovedel asi takhle: Pri cteni jakehokoli neobsazeneho portu procesor vzdy nacte hodnotu 255 (#FF). Ale co bylo mysleno tim poslednim bajtem na datove sbernici ? Bajty se po datove sbernici prenaseni smerem k nebo od CPU, ale pokud zadne zarizeni konkretni port nepouziva, zadna data na sbernici ani neposila a procesor cte jen stav, ktery by mel byt diky odporum prave 255. To znamena nacitat opakovane za sebou mnohokrat furt stejny port a sledovat, jestli vraci stabilne 255. Pokud ano, s nejvetsi pravdepodobnosti port neni obsazeny (alespon pro cteni je neobsazeny). VELESOFT
Re: RRD - detekce flash
Michal Hučík SHARP MZ-800
Netusim jak to je na jinych platformach, nicmene v MZ800 to tak skutecne je. Poslednim bajtem na datove sbernici je myslen posledni instrukcni bajt. Tedy: IN A,(#44) == 0xdb, 0x44 == pokud neni obsazen, tak prectes 0x44 LD C,#44 IN A,(C) == 0xed, 0x78 == pokud neni obsazen, tak prectes 0x78 Tedy 0xff neprectes na neobsazenem portu nikdy ;) Dne 20.3.2012 16:48, VELESOFT (SPRINTER) (sharpemupandora.cz) napsal(a):
Zobrazit citovaný text (44 řádků)
> > > ----- Original Message ----- From: "Michal Hučík > (sharpemupandora.cz)" <ordoz[doména skryta]> > To: "Konference "Počítač SHARP MZ-800 a emulátory"" <sharpemupandora.cz> > Sent: Tuesday, March 20, 2012 10:40 AM > Subject: Re: RRD - detekce flash > > >> >> >> Ahoj Martine, >> >> zda na nejakem portu visi nejake zarizeni, ktere umi vracet staticka >> data se pozna celkem jednoduse. instrukce IN na neobsazeny port totiz >> vraci vzdy stejnou hodnotu, jakou mel posledni byte na datove >> sbernici - v tomto pripade tedy posledni bajt instrukce IN. Test tedy >> muze postupne zkusit ruzne variace IN registr,(cislo) a IN >> registr,(C). Pokud tam je ROM disk, tak prectes pokazde stejnou >> hodnotu. Pokud tam neni nic, tak prectes hodnotu odpovidajici >> poslednimu bajtu instrukce IN. >> >> Michal >> > No ja teda logicky predpokladam, ze pokud procesor cte neobsazeny > port, mel by nacist hodnotu #FF, ktera by mela byt zajistena disky > internim pull-up odporum. Nemam shema Sharpa po ruce, ale pevne verim > tomu, ze tam odpory budou. Takze bych odpovedel asi takhle: > Pri cteni jakehokoli neobsazeneho portu procesor vzdy nacte hodnotu > 255 (#FF). > > Ale co bylo mysleno tim poslednim bajtem na datove sbernici ? Bajty se > po datove sbernici prenaseni smerem k nebo od CPU, ale pokud zadne > zarizeni konkretni port nepouziva, zadna data na sbernici ani neposila > a procesor cte jen stav, ktery by mel byt diky odporum prave 255. > > To znamena nacitat opakovane za sebou mnohokrat furt stejny port a > sledovat, jestli vraci stabilne 255. Pokud ano, s nejvetsi > pravdepodobnosti port neni obsazeny (alespon pro cteni je neobsazeny). > > VELESOFT > > ---
Re: RRD - detekce flash
Jardax SHARP MZ-800
Nemate nahodou tak trochu hokej v tom, ze jeden vypravite o prenosu instrukce z pameti do CPU a druhy o cteni portu do CPU? :) :) Jarda 20. březen 2012 17:12:30, Michal Hučík (sharpemupandora.cz) napsal:
Zobrazit citovaný text (64 řádků)
> > > Netusim jak to je na jinych platformach, nicmene v MZ800 to tak skutecne je. Poslednim bajtem na datove sbernici je myslen posledni instrukcni bajt. > > Tedy: > > IN A,(#44) == 0xdb, 0x44 == pokud neni obsazen, tak prectes 0x44 > > LD C,#44 > IN A,(C) == 0xed, 0x78 == pokud neni obsazen, tak prectes 0x78 > > Tedy 0xff neprectes na neobsazenem portu nikdy ;) > > > > Dne 20.3.2012 16:48, VELESOFT (SPRINTER) (sharpemupandora.cz) napsal(a): >> >> >> ----- Original Message ----- From: "Michal Hučík (sharpemupandora.cz)" <ordoz[doména skryta]> >> To: "Konference "Počítač SHARP MZ-800 a emulátory"" <sharpemupandora.cz> >> Sent: Tuesday, March 20, 2012 10:40 AM >> Subject: Re: RRD - detekce flash >> >> >>> >>> >>> Ahoj Martine, >>> >>> zda na nejakem portu visi nejake zarizeni, ktere umi vracet staticka data se pozna celkem jednoduse. instrukce IN na neobsazeny port totiz vraci vzdy stejnou hodnotu, jakou mel posledni byte na datove sbernici - v tomto pripade tedy posledni bajt instrukce IN. Test tedy muze postupne zkusit ruzne variace IN registr,(cislo) a IN registr,(C). Pokud tam je ROM disk, tak prectes pokazde stejnou hodnotu. Pokud tam neni nic, tak prectes hodnotu odpovidajici poslednimu bajtu instrukce IN. >>> >>> Michal >>> >> No ja teda logicky predpokladam, ze pokud procesor cte neobsazeny port, mel by nacist hodnotu #FF, ktera by mela byt zajistena disky internim pull-up odporum. Nemam shema Sharpa po ruce, ale pevne verim tomu, ze tam odpory budou. Takze bych odpovedel asi takhle: >> Pri cteni jakehokoli neobsazeneho portu procesor vzdy nacte hodnotu 255 (#FF). >> >> Ale co bylo mysleno tim poslednim bajtem na datove sbernici ? Bajty se po datove sbernici prenaseni smerem k nebo od CPU, ale pokud zadne zarizeni konkretni port nepouziva, zadna data na sbernici ani neposila a procesor cte jen stav, ktery by mel byt diky odporum prave 255. >> >> To znamena nacitat opakovane za sebou mnohokrat furt stejny port a sledovat, jestli vraci stabilne 255. Pokud ano, s nejvetsi pravdepodobnosti port neni obsazeny (alespon pro cteni je neobsazeny). >> >> VELESOFT >> >> --- > > > --- >
Re: RRD - detekce flash
Michal Hučík SHARP MZ-800
Dne 20.3.2012 17:17, Jardax (sharpemupandora.cz) napsal(a):
Zobrazit citovaný text (4 řádky)
> > Nemate nahodou tak trochu hokej v tom, ze jeden vypravite o prenosu > instrukce z pameti do CPU a druhy o cteni portu do CPU? > :) :)
Mozne je vse, nicmene smerodatny je v tomto pripade predevsim obsah registru (v tomto pripade A) do ktereho se cetlo pri testovaci instrukci IN, coz je mozno vyzkouset jak na Sharpu, tak ve Zdenkove emulatoru. Michal
Re: RRD - detekce flash
Jardax SHARP MZ-800
Jo, uz to vidim, nejak mi to v te diskusi uteklo. Nicmene mne to docela zarazi, protoze bych ocekaval FF, presne jak pise Velesoft. Koneckoncu instrukce probehla a cteni melo obsah registru prepsat, obzvlast pokud volany port neexistuje - at uz ma pull-up rezistory nebo ne. Ne? Jarda 20. březen 2012 17:22:02, Michal Hučík (sharpemupandora.cz) napsal:
Zobrazit citovaný text (15 řádků)
> > Dne 20.3.2012 17:17, Jardax (sharpemupandora.cz) napsal(a): >> >> Nemate nahodou tak trochu hokej v tom, ze jeden vypravite o prenosu instrukce z pameti do CPU a druhy o cteni portu do CPU? >> :) :) > > Mozne je vse, nicmene smerodatny je v tomto pripade predevsim obsah registru (v tomto pripade A) do ktereho se cetlo pri testovaci instrukci IN, coz je mozno vyzkouset jak na Sharpu, tak ve Zdenkove emulatoru. > > Michal > > --- >
Re: RRD - detekce flash
Michal Hučík SHARP MZ-800
Jde o nedokumentovanou fci. Popsal to Zdenek ve svem dokumentu, ktery sem pred lety poslal. Nikdy jsem nezkoumal jak je to na sbernici realizovano. Kazdopadne pokud to nekdo bude chtit vyzkouset, tak pozor pokud mate v systemu zapojen FDC Horava! Ten totiz krome svych FDC portu obsazuje i dolnich 127 portu, kterym dela extenzi.... Kdysi mne to potrapilo a nazlobilo tak, ze jsem zmineny problem opravil behem 10 sekund stipacima klestema :) Michal Dne 20.3.2012 17:31, Jardax (sharpemupandora.cz) napsal(a):
Zobrazit citovaný text (29 řádků)
> > Jo, uz to vidim, nejak mi to v te diskusi uteklo. Nicmene mne to > docela zarazi, protoze bych ocekaval FF, presne jak pise Velesoft. > Koneckoncu instrukce probehla a cteni melo obsah registru prepsat, > obzvlast pokud volany port neexistuje - at uz ma pull-up rezistory > nebo ne. > Ne? > > Jarda > > 20. březen 2012 17:22:02, Michal Hučík (sharpemupandora.cz) napsal: >> >> Dne 20.3.2012 17:17, Jardax (sharpemupandora.cz) napsal(a): >>> >>> Nemate nahodou tak trochu hokej v tom, ze jeden vypravite o prenosu >>> instrukce z pameti do CPU a druhy o cteni portu do CPU? >>> :) :) >> >> Mozne je vse, nicmene smerodatny je v tomto pripade predevsim obsah >> registru (v tomto pripade A) do ktereho se cetlo pri testovaci >> instrukci IN, coz je mozno vyzkouset jak na Sharpu, tak ve Zdenkove >> emulatoru. >> >> Michal >> >> --- >> > > ---
Re: RRD - detekce flash
Radek Suk SHARP MZ-800
Velesofte v Sharovi zadne pull-up resistory na datove sbernici nejsou. Kazde zarizeni ktere vyda signal INT pri IM2 ma povinost dodat vektror preruseni, ne jako u ZX kde to za ULA dodavaji ty pull-up odpory. Jinak schema Shapra je http://www.sharpmz.org/mz-800/download/sm800.pdf A zde na strane 45 je obvod 9C (74ls245 v poli E9) a ten dela toto, ze vidite, ze kdyz na datove sbernici je posledni cteni posledniho bajtu IN instrukce, tak se tato logicka hodnota prenese na konektor T9. Pri instrukci IN se jen prepne smer tohoto obvodu a tak se na urcitou dobu udrzi informace na konektoru T9 vlivem parazitni kapacity. Da se rici se je to "polovicni" aktivni terminator - zakladni princip je stejny - "odebere" nebo doda energii na T9 a te nejakou dobu trva nez se da do nedefinovaneho stavu. Rozhodne bych ale toho nepouzil v necem co maji pouzivat ostatni lide. Je to totalni hazard a muze to blbnout. Staci jen staticka elektrina. Proste vodice jsou v "luftu". Radek Dne 20.3.2012 18:35, Michal Hučík (sharpemupandora.cz) napsal(a):
Zobrazit citovaný text (49 řádků)
> > > Jde o nedokumentovanou fci. Popsal to Zdenek ve svem dokumentu, ktery > sem pred lety poslal. Nikdy jsem nezkoumal jak je to na sbernici > realizovano. > > Kazdopadne pokud to nekdo bude chtit vyzkouset, tak pozor pokud mate v > systemu zapojen FDC Horava! Ten totiz krome svych FDC portu obsazuje i > dolnich 127 portu, kterym dela extenzi.... Kdysi mne to potrapilo a > nazlobilo tak, ze jsem zmineny problem opravil behem 10 sekund > stipacima klestema :) > > Michal > > Dne 20.3.2012 17:31, Jardax (sharpemupandora.cz) napsal(a): >> >> Jo, uz to vidim, nejak mi to v te diskusi uteklo. Nicmene mne to >> docela zarazi, protoze bych ocekaval FF, presne jak pise Velesoft. >> Koneckoncu instrukce probehla a cteni melo obsah registru prepsat, >> obzvlast pokud volany port neexistuje - at uz ma pull-up rezistory >> nebo ne. >> Ne? >> >> Jarda >> >> 20. březen 2012 17:22:02, Michal Hučík (sharpemupandora.cz) napsal: >>> >>> Dne 20.3.2012 17:17, Jardax (sharpemupandora.cz) napsal(a): >>>> >>>> Nemate nahodou tak trochu hokej v tom, ze jeden vypravite o prenosu >>>> instrukce z pameti do CPU a druhy o cteni portu do CPU? >>>> :) :) >>> >>> Mozne je vse, nicmene smerodatny je v tomto pripade predevsim obsah >>> registru (v tomto pripade A) do ktereho se cetlo pri testovaci >>> instrukci IN, coz je mozno vyzkouset jak na Sharpu, tak ve Zdenkove >>> emulatoru. >>> >>> Michal >>> >>> --- >>> >> >> --- > > > --- > >
Re: RRD - detekce flash
Zdenek Adler SHARP MZ-800
Je to skutečně tak jak píše Michal - ti kteří nevěří, nechť si to na Sharpovi zkusí. Když jsem začal psát emulátor, také jsem logicky na všech neobsazených portech vracel 0xFF. K poznání že tomu tak není mě dovedla až jedna "špatně" přepsaná hra ze ZX Spectra (mlhavě si vzpomínám Exolon, ale to už asi jen hádám). Jednoduše se ve hře program větvil na základě čtení portu který na MZ není obsazený a při vracení hodnoty 0xFF hra zůstávala zatuhlá. Zdenek
Zobrazit citovaný text (52 řádků)
----- Original Message ----- From: "Michal Hučík (sharpemupandora.cz)" <ordoz[doména skryta]> To: "Konference "Počítač SHARP MZ-800 a emulátory"" <sharpemupandora.cz> Sent: Tuesday, March 20, 2012 6:35 PM Subject: Re: RRD - detekce flash > > > Jde o nedokumentovanou fci. Popsal to Zdenek ve svem dokumentu, ktery sem > pred lety poslal. Nikdy jsem nezkoumal jak je to na sbernici realizovano. > > Kazdopadne pokud to nekdo bude chtit vyzkouset, tak pozor pokud mate v > systemu zapojen FDC Horava! Ten totiz krome svych FDC portu obsazuje i > dolnich 127 portu, kterym dela extenzi.... Kdysi mne to potrapilo a > nazlobilo tak, ze jsem zmineny problem opravil behem 10 sekund stipacima > klestema :) > > Michal > > Dne 20.3.2012 17:31, Jardax (sharpemupandora.cz) napsal(a): >> >> Jo, uz to vidim, nejak mi to v te diskusi uteklo. Nicmene mne to docela >> zarazi, protoze bych ocekaval FF, presne jak pise Velesoft. Koneckoncu >> instrukce probehla a cteni melo obsah registru prepsat, obzvlast pokud >> volany port neexistuje - at uz ma pull-up rezistory nebo ne. >> Ne? >> >> Jarda >> >> 20. březen 2012 17:22:02, Michal Hučík (sharpemupandora.cz) napsal: >>> >>> Dne 20.3.2012 17:17, Jardax (sharpemupandora.cz) napsal(a): >>>> >>>> Nemate nahodou tak trochu hokej v tom, ze jeden vypravite o prenosu >>>> instrukce z pameti do CPU a druhy o cteni portu do CPU? >>>> :) :) >>> >>> Mozne je vse, nicmene smerodatny je v tomto pripade predevsim obsah >>> registru (v tomto pripade A) do ktereho se cetlo pri testovaci instrukci >>> IN, coz je mozno vyzkouset jak na Sharpu, tak ve Zdenkove emulatoru. >>> >>> Michal >>> >>> --- >>> >> >> --- > > > ---
Re: RRD - detekce flash
Michal Hučík SHARP MZ-800
Radku, mam pocit, ze jsem kdysi tento typ testu videl i v nektere variante cp/m, jako test RD takze bych se toho zase az tak nebal ... Kdykoliv jsem tuto metodu testoval (naposledy vcera), tak jsem precetl hodnotu jakou jsem ocekaval. Pokud se vratime k puvodnimu dotazu - jak obecne otestovat neobsazene porty pomoci instrukce IN, tak je tohle jediny zpusob, jaky mame k dispozici. Michal Dne 21.3.2012 9:18, Radek Suk (sharpemupandora.cz) napsal(a):
Zobrazit citovaný text (79 řádků)
> > > > Velesofte v Sharovi zadne pull-up resistory na datove sbernici nejsou. > Kazde zarizeni ktere vyda signal INT pri IM2 ma povinost dodat vektror > preruseni, ne jako u ZX kde to za ULA dodavaji > ty pull-up odpory. > > Jinak schema Shapra je http://www.sharpmz.org/mz-800/download/sm800.pdf > > A zde na strane 45 je obvod 9C (74ls245 v poli E9) a ten dela toto, ze > vidite, ze kdyz na datove sbernici je posledni cteni posledniho bajtu > IN instrukce, tak se tato logicka > hodnota prenese na konektor T9. Pri instrukci IN se jen prepne smer > tohoto obvodu a tak se na urcitou dobu udrzi informace na konektoru T9 > vlivem parazitni kapacity. Da se rici > se je to "polovicni" aktivni terminator - zakladni princip je stejny - > "odebere" nebo doda energii na T9 a te nejakou dobu trva nez se da do > nedefinovaneho stavu. > Rozhodne bych ale toho nepouzil v necem co maji pouzivat ostatni lide. > Je to totalni hazard a muze to blbnout. Staci jen staticka elektrina. > Proste vodice jsou v "luftu". > > Radek > > > Dne 20.3.2012 18:35, Michal Hučík (sharpemupandora.cz) napsal(a): >> >> >> Jde o nedokumentovanou fci. Popsal to Zdenek ve svem dokumentu, ktery >> sem pred lety poslal. Nikdy jsem nezkoumal jak je to na sbernici >> realizovano. >> >> Kazdopadne pokud to nekdo bude chtit vyzkouset, tak pozor pokud mate >> v systemu zapojen FDC Horava! Ten totiz krome svych FDC portu >> obsazuje i dolnich 127 portu, kterym dela extenzi.... Kdysi mne to >> potrapilo a nazlobilo tak, ze jsem zmineny problem opravil behem 10 >> sekund stipacima klestema :) >> >> Michal >> >> Dne 20.3.2012 17:31, Jardax (sharpemupandora.cz) napsal(a): >>> >>> Jo, uz to vidim, nejak mi to v te diskusi uteklo. Nicmene mne to >>> docela zarazi, protoze bych ocekaval FF, presne jak pise Velesoft. >>> Koneckoncu instrukce probehla a cteni melo obsah registru prepsat, >>> obzvlast pokud volany port neexistuje - at uz ma pull-up rezistory >>> nebo ne. >>> Ne? >>> >>> Jarda >>> >>> 20. březen 2012 17:22:02, Michal Hučík (sharpemupandora.cz) napsal: >>>> >>>> Dne 20.3.2012 17:17, Jardax (sharpemupandora.cz) napsal(a): >>>>> >>>>> Nemate nahodou tak trochu hokej v tom, ze jeden vypravite o >>>>> prenosu instrukce z pameti do CPU a druhy o cteni portu do CPU? >>>>> :) :) >>>> >>>> Mozne je vse, nicmene smerodatny je v tomto pripade predevsim obsah >>>> registru (v tomto pripade A) do ktereho se cetlo pri testovaci >>>> instrukci IN, coz je mozno vyzkouset jak na Sharpu, tak ve Zdenkove >>>> emulatoru. >>>> >>>> Michal >>>> >>>> --- >>>> >>> >>> --- >> >> >> --- >> >> > > > ---
Re: RRD - detekce flash
Radek Suk SHARP MZ-800
Ja nerikam ze to nefunguje, jen ze je to hazardni stav a nemelo by se to pouzivat. Co kdyz nekdo si udela posilovac sbernice a ten bude mit jine dynamicke vlastnosti? Pak mu to nepujde a pritom on ma vse dle norem. To muze byt zpusobeno napr. tim ze rekne ze /G vstup LS245 bude aktivni jen pri /IORQ a tak se "nenabije" druha cast a pri operaci se vrati nedefinovana hodnota nebo mozna ty 0FFh. Proste MREQ pozadavky se nebudou prenaset na druhou stranu obvodu. Take otazka je, jak se to bude chovat pri pripojeni napr. MZ-1U06, skoda ze to nikdo nema. Proste problem "dlouheho vedeni" zde je a neni vhodne to ignorovat, kdyz stav sbernice neni definovany a je nachylny k preslechum. Radek Dne 21.3.2012 9:52, Michal Hučík (sharpemupandora.cz) napsal(a):
Zobrazit citovaný text (99 řádků)
> > > Radku, mam pocit, ze jsem kdysi tento typ testu videl i v nektere > variante cp/m, jako test RD takze bych se toho zase az tak nebal ... > Kdykoliv jsem tuto metodu testoval (naposledy vcera), tak jsem precetl > hodnotu jakou jsem ocekaval. > > Pokud se vratime k puvodnimu dotazu - jak obecne otestovat neobsazene > porty pomoci instrukce IN, tak je tohle jediny zpusob, jaky mame k > dispozici. > > Michal > > > Dne 21.3.2012 9:18, Radek Suk (sharpemupandora.cz) napsal(a): >> >> >> >> Velesofte v Sharovi zadne pull-up resistory na datove sbernici >> nejsou. Kazde zarizeni ktere vyda signal INT pri IM2 ma povinost >> dodat vektror preruseni, ne jako u ZX kde to za ULA dodavaji >> ty pull-up odpory. >> >> Jinak schema Shapra je http://www.sharpmz.org/mz-800/download/sm800.pdf >> >> A zde na strane 45 je obvod 9C (74ls245 v poli E9) a ten dela toto, >> ze vidite, ze kdyz na datove sbernici je posledni cteni posledniho >> bajtu IN instrukce, tak se tato logicka >> hodnota prenese na konektor T9. Pri instrukci IN se jen prepne smer >> tohoto obvodu a tak se na urcitou dobu udrzi informace na konektoru >> T9 vlivem parazitni kapacity. Da se rici >> se je to "polovicni" aktivni terminator - zakladni princip je stejny >> - "odebere" nebo doda energii na T9 a te nejakou dobu trva nez se da >> do nedefinovaneho stavu. >> Rozhodne bych ale toho nepouzil v necem co maji pouzivat ostatni >> lide. Je to totalni hazard a muze to blbnout. Staci jen staticka >> elektrina. Proste vodice jsou v "luftu". >> >> Radek >> >> >> Dne 20.3.2012 18:35, Michal Hučík (sharpemupandora.cz) napsal(a): >>> >>> >>> Jde o nedokumentovanou fci. Popsal to Zdenek ve svem dokumentu, >>> ktery sem pred lety poslal. Nikdy jsem nezkoumal jak je to na >>> sbernici realizovano. >>> >>> Kazdopadne pokud to nekdo bude chtit vyzkouset, tak pozor pokud mate >>> v systemu zapojen FDC Horava! Ten totiz krome svych FDC portu >>> obsazuje i dolnich 127 portu, kterym dela extenzi.... Kdysi mne to >>> potrapilo a nazlobilo tak, ze jsem zmineny problem opravil behem 10 >>> sekund stipacima klestema :) >>> >>> Michal >>> >>> Dne 20.3.2012 17:31, Jardax (sharpemupandora.cz) napsal(a): >>>> >>>> Jo, uz to vidim, nejak mi to v te diskusi uteklo. Nicmene mne to >>>> docela zarazi, protoze bych ocekaval FF, presne jak pise Velesoft. >>>> Koneckoncu instrukce probehla a cteni melo obsah registru prepsat, >>>> obzvlast pokud volany port neexistuje - at uz ma pull-up rezistory >>>> nebo ne. >>>> Ne? >>>> >>>> Jarda >>>> >>>> 20. březen 2012 17:22:02, Michal Hučík (sharpemupandora.cz) napsal: >>>>> >>>>> Dne 20.3.2012 17:17, Jardax (sharpemupandora.cz) napsal(a): >>>>>> >>>>>> Nemate nahodou tak trochu hokej v tom, ze jeden vypravite o >>>>>> prenosu instrukce z pameti do CPU a druhy o cteni portu do CPU? >>>>>> :) :) >>>>> >>>>> Mozne je vse, nicmene smerodatny je v tomto pripade predevsim >>>>> obsah registru (v tomto pripade A) do ktereho se cetlo pri >>>>> testovaci instrukci IN, coz je mozno vyzkouset jak na Sharpu, tak >>>>> ve Zdenkove emulatoru. >>>>> >>>>> Michal >>>>> >>>>> --- >>>>> >>>> >>>> --- >>> >>> >>> --- >>> >>> >> >> >> --- > > > --- > >
Re: RRD - detekce flash
Fuzzy SHARP MZ-800
Ahoj,
dik za nazory a informace. Udelal bych to tedy takhle:
- projedu celou (potencialni) 64kB stranku romdisku kombinacemi
instrukci "in a, (xx)" a "in r,(c)" nekolikrat pro kazdy bajt RD;
jestli:
- vsude bude stejna (jakakoliv) hodnota, RD tam neni (anebo ma
neprilis smysluplny obsah, pak je to stejne jedno :-)
- se pro jakykoliv bajt nactou ruzne hodnoty ruznymi instrukcemi,
RD tam taky neni
- jinak je to stranka romdisku a udelam z nej "read-only block device" pro
mzix
zkoumani 1. bajtu na konkretni hodnotu 0xA5, eventualne crc kontrolu
bych nedelal, kdo vi co si kdo vymysli za alternativni (treba
nebootovatelny) obsah romdisku.
vidite v tom nekdo nejaky problem?
Fuzzy
2012/3/21 Radek Suk (sharpemupandora.cz) <suk[doména skryta]>:
Zobrazit citovaný text (129 řádků)
> > > Ja nerikam ze to nefunguje, jen ze je to hazardni stav a nemelo by se to > pouzivat. Co kdyz nekdo si udela posilovac sbernice a ten bude mit jine > dynamicke vlastnosti? Pak mu to nepujde a pritom on ma vse dle norem. To > muze byt zpusobeno napr. tim ze rekne ze /G vstup LS245 bude aktivni jen pri > /IORQ a tak se "nenabije" druha cast a pri operaci se vrati nedefinovana > hodnota nebo mozna ty 0FFh. Proste MREQ pozadavky se nebudou prenaset na > druhou stranu obvodu. Take otazka je, jak se to bude chovat pri pripojeni > napr. MZ-1U06, skoda ze to nikdo nema. Proste problem "dlouheho vedeni" zde > je a neni vhodne to ignorovat, kdyz stav sbernice neni definovany a je > nachylny k preslechum. > > > Radek > > > > Dne 21.3.2012 9:52, Michal Hučík (sharpemupandora.cz) napsal(a): > >> >> >> Radku, mam pocit, ze jsem kdysi tento typ testu videl i v nektere variante >> cp/m, jako test RD takze bych se toho zase az tak nebal ... Kdykoliv jsem >> tuto metodu testoval (naposledy vcera), tak jsem precetl hodnotu jakou jsem >> ocekaval. >> >> Pokud se vratime k puvodnimu dotazu - jak obecne otestovat neobsazene >> porty pomoci instrukce IN, tak je tohle jediny zpusob, jaky mame k >> dispozici. >> >> Michal >> >> >> Dne 21.3.2012 9:18, Radek Suk (sharpemupandora.cz) napsal(a): >>> >>> >>> >>> >>> Velesofte v Sharovi zadne pull-up resistory na datove sbernici nejsou. >>> Kazde zarizeni ktere vyda signal INT pri IM2 ma povinost dodat vektror >>> preruseni, ne jako u ZX kde to za ULA dodavaji >>> ty pull-up odpory. >>> >>> Jinak schema Shapra je http://www.sharpmz.org/mz-800/download/sm800.pdf >>> >>> A zde na strane 45 je obvod 9C (74ls245 v poli E9) a ten dela toto, ze >>> vidite, ze kdyz na datove sbernici je posledni cteni posledniho bajtu IN >>> instrukce, tak se tato logicka >>> hodnota prenese na konektor T9. Pri instrukci IN se jen prepne smer >>> tohoto obvodu a tak se na urcitou dobu udrzi informace na konektoru T9 >>> vlivem parazitni kapacity. Da se rici >>> se je to "polovicni" aktivni terminator - zakladni princip je stejny - >>> "odebere" nebo doda energii na T9 a te nejakou dobu trva nez se da do >>> nedefinovaneho stavu. >>> Rozhodne bych ale toho nepouzil v necem co maji pouzivat ostatni lide. Je >>> to totalni hazard a muze to blbnout. Staci jen staticka elektrina. Proste >>> vodice jsou v "luftu". >>> >>> Radek >>> >>> >>> Dne 20.3.2012 18:35, Michal Hučík (sharpemupandora.cz) napsal(a): >>>> >>>> >>>> >>>> Jde o nedokumentovanou fci. Popsal to Zdenek ve svem dokumentu, ktery >>>> sem pred lety poslal. Nikdy jsem nezkoumal jak je to na sbernici >>>> realizovano. >>>> >>>> Kazdopadne pokud to nekdo bude chtit vyzkouset, tak pozor pokud mate v >>>> systemu zapojen FDC Horava! Ten totiz krome svych FDC portu obsazuje i >>>> dolnich 127 portu, kterym dela extenzi.... Kdysi mne to potrapilo a >>>> nazlobilo tak, ze jsem zmineny problem opravil behem 10 sekund stipacima >>>> klestema :) >>>> >>>> Michal >>>> >>>> Dne 20.3.2012 17:31, Jardax (sharpemupandora.cz) napsal(a): >>>>> >>>>> >>>>> Jo, uz to vidim, nejak mi to v te diskusi uteklo. Nicmene mne to docela >>>>> zarazi, protoze bych ocekaval FF, presne jak pise Velesoft. Koneckoncu >>>>> instrukce probehla a cteni melo obsah registru prepsat, obzvlast pokud >>>>> volany port neexistuje - at uz ma pull-up rezistory nebo ne. >>>>> Ne? >>>>> >>>>> Jarda >>>>> >>>>> 20. březen 2012 17:22:02, Michal Hučík (sharpemupandora.cz) napsal: >>>>>> >>>>>> >>>>>> Dne 20.3.2012 17:17, Jardax (sharpemupandora.cz) napsal(a): >>>>>>> >>>>>>> >>>>>>> Nemate nahodou tak trochu hokej v tom, ze jeden vypravite o prenosu >>>>>>> instrukce z pameti do CPU a druhy o cteni portu do CPU? >>>>>>> :) :) >>>>>> >>>>>> >>>>>> Mozne je vse, nicmene smerodatny je v tomto pripade predevsim obsah >>>>>> registru (v tomto pripade A) do ktereho se cetlo pri testovaci instrukci IN, >>>>>> coz je mozno vyzkouset jak na Sharpu, tak ve Zdenkove emulatoru. >>>>>> >>>>>> Michal >>>>>> >>>>>> --- >>>>>> >>>>> >>>>> --- >>>> >>>> >>>> >>>> --- >>>> >>>> >>> >>> >>> --- >> >> >> >> --- >> >> > > > ---