OldComp.cz

O co se jedna? Koukal jsem do manualu STM32F4 a nejak tam nic takoveho nevidim. Je tam jen push-pull/open-drain + pull-up/down. Myslis tohle?

Jinak chapu-li spravne, tak UNICARD sniffuje zapisy do video-RAM + obsluhuje par portu (RD i WR) - tam je sance kolize podstatne mensi, nez pri obsluze cteni ze spousty adres. Ono to neni jen o chybach ve firmwaru. Kdyby se chtel clovek vyhnout kolizi, tak si nemuze dat do kodu ani breakpoint (resp. muze, ale nesmi ho dat nekam, kde bude datova sbernice aktivni ze strany ARMu). A toho se mi nechce uplne vzdat.

Dokazal by nekdo odhadnout, kdyz jsou v Didaktiku Gama na datove sbernici (D0..7) povesene CPU, ULA a pameti (resp. nejake buffery pred nima), jaky proudy tam tecou? Tedy jestli ty moje ochranne odpory + 3.3V logika nedelaji nejak problem v urceni urovni?

EDIT: Oprava, buffery, resp. MUXy jsou na adresove sbernici. Na datove jsou pameti, ULA, 8255 PIO.

Kdyz koukam na schema http://speccy.wz.cz/schemata/gama.gif tak jediny zajimavy proud co je na datove sbernici je, kdyz ARM dava log0 a je to 5/(8200+120)=0,6mA coz je maly proud. Spise bych se zajimal o kapacity a jak strme jsou hrany signalu. Kdyz napr. vpravo od 8x470 ohmu bude dosti velka kapacita tak chvilku bude trvat jez se to vybije, ten odpor tomu brani. Ale jako celek bych zde nehledal problem a spise bych se zameril na firmware ARM.

Urcite musis zajistit ze ARM bude vzdy v Z stavu a do log0 nebo log1 pujde jen v pripade ze odpovida na sbernici on. V kazdem pripade musis zajistit ze po tuto dobu nesmis prerusit praci ARM aby se ti nestalo ze ho zastavis a pocitac ti bude pokracovat v praci. V tom pripade si neco muzes znicit. Reseni je dat nejake 5V CPLD mezi pocitac a ARM. Jednoduchy stavovy automat ti zajisti ze kdyz se sam neodpojis od sbernice tak to udela CPLD za tebe na konci RD cyklu (pripadne INTA cyklu).

Ne ne, myslím to, co je v datasheetu označeno jako "speed" v rozsahu 2,25,50,100MHz, to určuje špičkový proud při změně log. úrovně.

Mám i verzi pro MZ700, kde unikarta krom všeho co u MZ800 i emuluje externí 8KB ROM. A opravdu to není jenom o chybách, je to o koncepci, kolize jsou vyřešené tím, že se nejdřív vybaví WAIT a pak unikarta řeší datovou sběrnici, takže i kdyby nakrásně nestíhala vystavit data a shodit WAIT, tak proběhne wait state navíc a jede se v pohodě dál, k hazardu nedojde.

Tak hura! Uz mi Gama "bootuje" do ROM, kterou emuluje ARM

Hlavni problem byl skutecne v tech ochrannych 8x 120R odporech na datove sbernici mezi ARMem a Z80. Asi kdyz ULA vycitala z video RAM zrovna neco na "sve" datove sbernici (oddelene pres 8x 470R od Z80), zatimco ARM cpal do Z80 pres 120R neco jineho, mohlo z toho pravdepodobne vyjit hranicni napeti pro rozliseni 1/0. Bohuzel osciloskop nemam, abych to overil, ale snizeni odporu na 33R pomohlo.

Tu teorii jsem myslim vyvratil i bez osciloskopu tim, ze jsem vybavoval WAIT a drzel "sva" data hodne dlouho na datove sbernici (tedy mely by se kapacity bez problemu stihnout nabit/vybit) - nepomahalo to.

Zkousel jsem emulovat cartridge (ROMky) pro Interface 2 http://www.worldofspectrum.org/pub/sinc ... ace2-roms/ a za ten pocit, kdyz "instantne" nabehnuli Space Raiders (Invaders) to stalo

Zatim diky vsem za napady a pripominky, ted uz zbyva "jen" nacitani a ukladani snaphotu atd...

To vypadá na nějaký vakl na sběrnici daný kombinací 3.3V a 5V logiky, chtělo vy to asi nějaký level shifter.
Spectra s originál ULA Wait nepoužívají, jen IF1 pro synchronizaci s Microdrive. ULA pozastavuje hodiny Z80, když dojde ke kolizi zájmů.
Ruská ULA v Didaktiku M a Kompakt naopak používá k brždění Wait, takže tady by ses asi o něj přetahoval.
Wait nesmí být dlouho, jinak vyšumí obsah z DRAM.
Ten půlcyklus na konci M1 je samozřejmě Refresh.

Já bych tam dal 8K ROM a 8K SRAM stínované do ROM, popřípadě víc stránkované. A ARM by chytal jen I/O cykly.

Sehnal jsem sponzora (alespon co se tyce HW) na vyvoj - hkfree.org - takze budu mit moznost se na ty signaly konecne mrknout osciloskopem, aby bylo jasne, o co tam slo a poladit to.

Tech reseni, ktera maji externi RAM/ROM je uz dost. Me slo o to prave nacpat vse do ARMu. Ono by to mohlo jit (napr. u toho dual-core LPC) i bez nutnosti WAITovat (resp. vybavovat WAIT jen pro sichr, ale pri trose stesti tim vubec zpracovani instrukci neprodluzovat - tj. vejit se do casovani jakoby bez WAITu). Tu myslenku externi RAM podporuje z meho pohledu snad jen to, ze nejvetsi interni SRAM ma z pouzitelnych MCU STM32F7 a to porad "jen" 512kB, takze kdybychom tim chteli emulovat periferie s vice RAM (napr. pro ResiDOS), tak to externi RAM vyzaduje.

Pretahovani o WAIT u ruske ULA by slad nemuselo vadit. Resp. WAIT je podobne jako ostatni sdilene signaly mezi CPU a vice periferiema delany snad jako otevreny kolektor + pullup (soudim podle negovane logiky a externiho pullupu).

Taky myslím na STM32Fx. Jsou poměrně dost výkonné.
Existuje emulátor MZ800 Speccyho a PMD 85 a ten stihne generovat obraz pomocí SPI a ještě emulovat procesor.
Pokud budeš emulovat diskový řadič na SD kartě, tak se možná obejdeš i bez Wait, v reálu taky trvá, než pod hlavu přijede sektor a za tu dobu přečteš z karty.

odpory určitě ano, kdyby nastaly kolize

FYI projekt zije zde: https://github.com/pavkriz/zx-uniper/

Trochu jsem se ted zaseknul na nasledujicim: Emuluju divIDE (32kB RAM) s nahranym esxdosem 0.8.5. Po navratu z NMI browseru (SPACE v browseru) se mi neobnovi video RAM (zustava tam obsah z browseru a bezici program ho pripadne postupne prekresluje). Jak to ma v esxdosu fungovat? Nekde jsem cetl, ze ma pri NMI ukladat video RAM (screen) na disk (kam?). Nebo se esxdos nejak snazi zjistit, kolik RAM je v divIDE a muze to zkouset nekdy ukladat do dalsi RAM v divIDE?

Podle logu vidim, ze se esxdos nesnazi pri NMI nic na disk ukladat. Nicmene pri navratu z NMI browseru vidim, ze se snazi vycist obsah disku (root directory), "jako by neco hledal". To me privadi na stopu, ze se mozna snazi obnovit video RAM z disku. Otazka zni, proc ji tam na zacatku NMI neuklada? Je mozne, ze nejakymi okolnostmi vydedukuje, ze to nema delat?

Odpovidam si sam: musi existovat adresar \TMP na disku, kam se do souboru _nmi_bkp.scr zalohuje video RAM behem NMI. Pokud TMP adresar neexistuje, nic to nehlasi a vysledek je viz vyse (ztrata obsahu video RAM).

PS: Misto disassemblovani a analyzy retezcu v NMI.SYS by si byvalo stacilo precist README k esxdosu (vcetne informaci v zavorkach)

Pokud ma divide více paměti, ukláda snad obsah videoram do rozšířené paměti a nevyužívá ani složku tmp. Jak je to ale přesně ti nepovím. Dokumentace k esxdosu je hodně bídná...

Odesláno z mého SM-G928F pomocí Tapatalk

_________________
>>eLeMeNt, MB03+, Amiga 1200, ZX Spectrum 128 +2A, ZX Spectrum+, Didaktik Gama, LnxSpectrum, LnxTracker, LnxAmigaImageConvertor, https://www.ilnx.cz <<

Vsiml jsem si, ze v esxdosu (0.8.0 i 0.8.5) ne vzdycky spolehlive zafunguje navrat z NMI browseru - tj. SPACE z NMI. Obcas u nekterych programu to ten program nejak nakopne a ten se ruznym zpusobem rozsype. Deje se mi to i ve FUSE emulatoru, takze soudim, ze to je nejaky obecny problem (skutecne divIDE nevlastnim, abych to overil na nem).

Kokretni postup: NMI, vyberu HATE.tap http://www.worldofspectrum.org/infoseek ... id=0002247 (jedno kterou verzi), zmacknu 5 = DEMO, demo bezi, NMI, SPACE, NMI, SPACE,... a tak do cca 5 pokusu to po navratu z NMI crashne.

Je to chyba? Da se cekat, ze to program vzdycky rozdejcha? Matne si pamatuju z D80 resp. Didaktiku Kompakt, ze po NMI to programy ne vzdy rozdejchaly...

Ten STM, co pouzivas - to je nejakej kit, nebo to mas holej cip na nejakem univerzalnim TQFP adapteru?

_________________
Nikdy nediskutujte s blbcem. Stáhne vás na svoji úroveň a vyhraje zkušeností.