Wiadomo, jednak niestety czas pomiędzy CS a ficzyną akcją na liniach data jest dla mnie kluczowy ponieważ chciałbym ocenić czy mozliwe jest wystarczająco szybkie wystawienie danych uzyając CPU a nie CPLD/FPGA. Ponieważ mam bardzo malo czasu na wystawienie danych muszę wiedzieć ile on zajmuje z dokładnością do cyklu maszynowego *mojego* cpu. Mam około 30ns na instrukcję w najlepszej sytuacji. Po pojawieniu się CS musze sekwencyjnie: przyjąć przerwanie, zorientować się czy read czy write, odczytać adres, zmienić kierunek lini data dla odczytu, wystawić pobrać daną. Szacuje czy to w ogóle wykonalne. Niestety bez czasu CS w stosunku do FI2 mogę tylko z grubsza.

Chyba jednak musze podpiąc oscyloskop żeby to oszacować.

Ale zmartwiłeś mnie: na CS mam glitcha. A wiadomo choć jak wielkiego? W sensie szerokości stanu niestabilnego? Rozumiem że pochodzi od z faktu że adres -> cs robiony jest przez zwykłą logikę kombinacyjną i nie ma tam zatrzasku?

Szacowanie jest niezbedne aby móc przejśc do etapu projektowania. Szacowanie jest mi potrzebne aby w worst-case mieć pojęcie ile mam czasu na reakcję. Wątpie żeby te 50ns było spotykane na busie, ale nie wykluczam.

PS. Nie dam wiary że pomiedzy różnymi modelami czas ten jest jakoś absurdalnie różny. I *nikt* kto projektuje hardware nie może dać gwarancji że zadziala na wszystkim. I nie o to chodzi. Chcę na pierwszy ogień mieć szacunek czy układ sekwencyjny taki jak CPU jest w stanie się wyrobić i w jakim czasie. IMHO nie da rady niczym popularnym, a propeller jest dośc drogi choć pewnie nadawał by się znakomicie. Więc zadaniem moim na początek jest wyeliminować na czym się nie da. Zapewne skończy się na cpld + cpu lub jakiejś innej hybrydzie bo małe fpga ciągle drogie...

Masz na myśli TOMEK-8 ? Jesli tak, to zacytuję autora:
"Zrezygnowalem z dekodowania adresow. Bo wymyslilem jak zrobic to wszystko co pokazalem w demie i co opisal XXL, bez podlaczania do koprocesora szyny adresowej".

Ja nie mam takiego komfortu, musze dekodować adresy i wybierac prawidłowe adresy w RAMie CPU. Mam wątpliwośc że cokolwiek poza propellerem się wyrobi. Za kilka dni oscyloskop wróci do życia to się zapewne dowiem ...

lepiej ustawic irq na rosnace zbocze iloczynu sygnalu not pokey_cs i phi2, bedziesz mial pare cykli na wczytanie adresu i danej z io
przy 16/32 bitowym mcu to bedzie jedna instrukcja

ale ale

to juz plyty glownej nie robisz?

Problem że te pare cykli to ciasno. Odczyt 6502 wymaga u mnie kilku instrukcji (wyłaczenie przerwań, odlożenie rejestru na stos, pobranie A, adresacja w pamięci wewnatrznej, pobranie z pamięci, zmiana kierunku portu itd, samo przyjęcie przerwania to będzie z 4 cykle). Ponadto procesory 16/32 zazwyczaj są niewiele szybsze. Na ten przykład SAM7S ma znacznie wolniejsze GPIO niz avr co jest o tyle zabawne że pochodzą od tego samego producenta a zegar SAM7 jest 5x większy niż AVR ale dla małych dupereli na drutach jest jakby mniej wydajny (rownież z powodu organizacji flash). Innymi słowy nie ma prostej zależności 16/32 bity -> szybciej. Się zobaczy, się pomyśli.

A niby dlaczego tak sądzisz? Obecnie składam system uC na 6510 wyszarpanym z C64 dla rozgrzewki lutownicy, a obecny temat ma trochę z tym (pcb) wspólnego. W gąbce obok siedzi AY z Z80 i też czeka na swoja kolej :)