Procesor NMOS i karta CF

Masz może video jak to działa?

Wyczuwam, że gdzieś między wierszami jest sugestia jakoby był jakiś problem między technologią NMOS a kartą CF, mógłbys zdradzić o co chodzi? Inne różnice poziomów logicznych?

Potem nakręcę i gdzieś wrzucę. Przy czym nie jestem pewien czy uda mi się zreprodukować sam błąd.

Też o tym myślałem, przy czym nie udało mi się na szybko znaleźć w internecie informacji o tym, czy i w jakim stopniu technologia NMOS różni się od CMOS (przy zasilaniu 5V). Noty katalogowe kart CF czasami ostrzegają przed niekompatybilnością ze standardem TTL. Ale czy można postawić znak równości pomiędzy NMOS i TTL w tym względzie - nie wiem...

No i w każdym razie problem jest dziwnie powtarzalny. Zawsze objawia się w ten sam sposób - czasem opóźnienie pomiędzy kolejnymi printowanymi wartościami jest mniejsze. Gdyby chodziło o poziomy napięć, to należałoby się spodziewać chaosu na magistrali i losowych przekłamań. W przypadku pojawienia się takich problemów program powinien przeważnie crashować, i to na różne sposoby. Tymczasem to się nie dzieje.

Zastanawiam się jeszcze czy przypadkiem komórka pamięci do której trafia ta konkretna wartość nie jest jakaś problematyczna - albo z powodu wewnętrznego uszkodzenia, albo przez kiepski kontakt z podstawką.

Zrobiłem kilka dodatkowych testów i wyniki są... Zaskakujące... Po pierwsze dodałem do kodu hexdump pierwszych 32 bajtów pamięci po załadowaniu kodu z karty CF. Cały programik ma zaledwie 20 bajtów, więc jest to wystarczająca liczba.

Zawartość binarnego pliku wygląda następująco: 21 FF 7F F9 C3 07 00 0E

Zawartość pamięci, gdy program printuje znaki szybko: 21 FF 7F F9 C3 07

Zawartość pamięci, gdy program printuje znaki wolno: 21 7F F9 C3 07 00

Już na pierwszy rzut oka widać, gdzie leży sedno problemu - pomijany jest drugi bajt o wartości 0xFF. Wbrew mojemu oryginalnemu założeniu, to szybkie printowanie jest poprawnym wynikiem. Wolniejsze działanie (chociaż występuje znacznie) częściej stanowi efekt działania błędu.

Wbrew moim podejrzeniom, błąd nie miesza w pętli opóźniającej, ale sabotuje początkowe ustawienie wartości stosu:

Wygląda więc na to, że w wyniku błedu do pary rejestrów HL trafia wartość 0x7ff9, ale rozkaz SPHL nie jest wykonywany (bo kod interpretuje jego wartość jako parametr instrukcji LXI). Wskaźnik stosu pozostaje więc taki, jakim ustawił go bootloader. Dlaczego powoduje to wolniejsze działanie programu? Nie mam pojęcia. Dlaczego ładowanie danych z karty odbywa się z tak zadziwiająco powtarzalnym błędem? Też nie wiem...

Poeksperymentuję jeszcze z kilkoma kartami. Jeśli jednak nie uda mi się znaleźć takiej, która będzie działała w 100% poprawnie, to trudno będzie myśleć o eksperymentach z CP/M. Pomyślałbym, że to faktycznie wina poziomów napięć i braku bufora. Tylko ta powtarzalność... Problem z niedopasowaniem poziomów napięć mógłby powodować losowe przekłamania bitów, ale nie konsystentne pomijanie całego bajtu...

Hm, o ile pamiętam, to CP/M miał sektory 128 Bajtów, a karta 512.

Na linuxie to robisz? Hm, nie jestem pewien, czy tak można, w pierwszym sektorze partycji powinny być określone dane w DOS/Windows. Jeli ich nie ma ... ciekawe, co zwariuje.

Do sprawdzenia - nie powinno być takich cudów. A jesli są, to gdzieś jest błąd :-)

Hm, a duży problem dodać? Bo jeśli to ma rozwiązać problemy ... to dodać od razu :-)

J.

Masz też przestawiony program o cały bajt. Wiec choćby ten LOOP, jest teraz pod adresem 0006, a skok jest nadal do 0007, czyli pomijasz pierwszy bajt pętli. Co tam jest istotnego, to sam musisz zobaczyc.

A jak czytasz? Spodziewam się, ze po ustawieniu numeru sektora i komendy odczytu go, wystarczy już odczytać kolejne bajty. Takie zniknięcie bajtu może być spowodowane:

-karta zobaczyła fałszywą informacje o odczycie bajtu, i przeskoczyła na następny. A to może być spowodowane właśnie poziomami napięcia, zakłóceniami elektrycznymi, itp. Ale czemu tylko pod drugim bajtem? A może wcale nie tylko pod drugim, i więcej bywa zgubione?

A wpisz tam inną wartość, np C0, w koncu możesz ustwic stos na

-przeskoczenie licznika/indeksu w bootloaderze? Ale jaki mógłby być powód, i czemu tylko na drugim bajcie.

Zrobiłbym też długi dump. I moze dodał do programu kilka tablic po 256B o kolejnych wartosciach

- zobaczysz na dumpie czy się poprawnie wczytują.

J.

Na tym etapie to jeszcze nie ma znaczenia. Teraz po prostu próbuję osiągnąć ten punkt, w którym binarny obraz systemu zapisany na określonej sekwencji sektorów karty (rozpoczynającej się w miejscu, gdzie w tabeli partycji wypada początek pierwszej partycji) trafia w odpowiednie miejsce RAM-u i zostaje wykonany. Geometrią dysku będę musiał się martwić dopiero wtedy, gdy zacznę uruchamiać niskopoziomowe procedury odpowiadające z dostęp do dysku. Tak naprawdę nie jestem tu pierwszy - istnieją projekty ludzi, którzy nauczyli CP/M korzystać z kart CF albo SD. Nie wspominając już o tym, że współczesne nośniki mają kolejno numerowane sektory LBA, podczas gdy dyski/dyskietki z epiki miały bardziej skomplikowaną geometrię. Trzeba będzie to przetłumaczyć. Bootloadera to wszystko jednak nie obchodzi - on po prostu kopiuje do RAM-u sekwencję 16kB, zaczynając od początku pierwszej partycji.

Tak.

To miałoby znaczenie, gdybym używał DOS-owych/windowsowych partycji. Tutaj jednak jedynym co mnie interesuje jest MBR i pierwsza partycja, która na chwilę obecną może być równie dobrze niesformatowana. Oczywiście dd nadpisze jej pierwszy sektor plikiem binarnym i nie będzie ona miała sensu dla współczesnych systemów, jednak mój komputerek po prostu odczyta sobie z tego miejsca obraz systemu i skopiuje go do pamięci. Na dalszym etapie nauczę CP/M traktować inną partycję (albo nawet tę samą, ale zaczynając od odpowiednio późniejszych sektorów) jak dysk systemowy.

W prototypie nie, bo tam karta CF znajduje się na osobnym module, połączonym z płyta główną za pomocą taśmy. Wystarczy, że zaprojektuję jeszcze jeden modulik wpinany między nie. Gorzej z wersją "finalną", z trawioną płytką. Tam się pospieszyłem i już umieściłem gniazdko karty CF na jednej z kilku płytek tworzących urządzenie. Teraz pewnie musiałbym zaprojektować jeszcze jeden moduł, z gniazdkiem i buforami, podpinany bezpośrednio do magistrali.

Masz rację. Jakoś mi to umknęło. ;)

Dokładnie tak. Całośc odbywa się względnie bezobsługowo. Po prostu zgłaszamy karcie ile sektorów chcemy odczytać i zaczynając od którego, a potem w pętli czytamy sprawdzając flagi ustawiane przez kartę.

LOAD_PARTITION1: ; Pod LOAD_BASE znajduje się już odczytany MBR LXI D, LOAD_BASE+446+8 LDAX D OUT CFREG3 ;LBA 0 INX D LDAX D OUT CFREG4 ;LBA 1 INX D LDAX D OUT CFREG5 ;LBA 2 INX D LDAX D ANI 0FH ;FILTER OUT LBA BITS ORI 0E0H ;MODE LBA, MASTER DEV OUT CFREG6 ;LBA 3 MVI A, 32 ;READ 32 SECTORS (16kB) OUT CFREG2 CALL CFWAIT MVI A, 20H ;READ SECTOR COMMAND OUT CFREG7 LXI D, LOAD_BASE CALL CFREAD CALL CFCHERR RET

CFREAD: CALL CFWAIT IN CFREG7 ANI 08H ;FILTER OUT DRQ JZ CFREADE IN CFREG0 ;READ DATA BYTE STAX D INX D JMP CFREAD CFREADE: RET

CFCHERR: IN CFREG7 ANI 01H ;MASK OUT ERROR BIT JZ CFNERR LXI D, CFERRM CALL PRTSTG IN CFREG1 MOV L, A MVI H, 0H MVI C, 4H CALL PRTNUM CFNERR: RET

Też o tym pomyślałem. Tym bardziej, że szukając na szybko trafiłem w Internecie na taką wypowiedź:

"From CPU speed of 7Mhz to 20MHz, the CF disk is generally fast enough that no wait state is needed. Slowing down or speeding up the CPU clock does not change the CF interface characteristic. The 'fast' or 'slow' CF disk refers to the rising and falling edges of the CF output signals. When the eight data lines of a fast CF disk simultaneously drive capacitive loads such as a backplane with many boards, especially from all 0's to all 1's, a large instaneous current is flowing out of the CF disk, which cause its ground to sink lower than the system reference ground. The ground negative spike is too brief to affect Z80 and older TTL technology, but the CF_read line see a brief positive spike when CF's ground is spiking down. The CF_read controls a FIFO, so a spike can cause the FIFO to advance to next data byte thus discarding current byte of data thus corrupt the data packet. In short, the data corruption is self inflicted that only 'fast' CF can generate the fast ground spike that the 'fast' CF_read can react to. For the 'slow' CF, the ground spike is of insufficient magnitude or duration to cause its 'slow' CF_read to skip a byte of data."

Też o tym pomyślałem, zrobię taki test.

Mało prawdopodobne. Instrukcja INX wykonuje się po każdym zapisanym bajcie. Musiałby ten jeden raz nie przeskoczyć, powodując nadpisanie tego 0xFF.

Będę musiał zmodyfikować kod hexdumpa, żeby wywalał to na RS232, bo na razie korzystam z ekranu. ;)

Ok. Wartość 0xC0 nie jest pomijana. Czyli ma problem faktycznie z 0xFF. Trzeba będzie poszukać innej karty, a docelowo zastosować bufory.

I jeszcze jedna kwestia, o której zapomniałem wspomnieć. To nie jest pierwszy raz, kiedy używam karty CF w projekcie z ośmiobitowym mikroprocesorem retro. Parę lat temu zbudowałem pewne urządzenie, które zapisywało dane w pliku na karcie. Wtedy działał tam już pełnoprawny system plików - po wprowadzeniu paru niezbędnych zmian udało mi się skompilować FatFS za pomocą CC65. Główne różnice w stosunku do obecnej sytuacji były trzy (jeśli nie liczyć faktu, że kod był napisany w C, a nie asemblerze):

1. Użyłem CPU 6502 zamiast 8080.
2. Procesor był w technologii CMOS, a nie NMOS.
3. Karta była znacznie większa (aby było miejsce na zapisywane dane).

Gdyby pojawiały się podobne problemy z gubionymi bajtami, FatFS momentalnie by się wykrzaczył. Tymczasem urządzenie poprawnie działało całymi miesiącami. Stawiam więc na to, że albo technologia procesora ma znaczenie, albo te małe przemysłowe karty (których używam obecnie) są szybsze od przeciętnych, większych, fotograficznych.

Sprawdziłem jakie inne karty CF mam pod ręką. Okazuje się, że jakiś tani EMTEC 512MB w zmęczonej życiem obudowie działa zupełnie poprawnie. A przynajmniej poprawnie ładuje testowy programik z wartością 0xFF. Nie wiem czy nie dodam dodatkowego checka do bootloadera - zliczanie odebranych bajtów i finalne sprawdzanie, czy skopiowane zostało faktycznie dokładnie 16kB. Nie uchroni mnie to przed przekłamanymi wartościami (chociaż tego problemu jak na razie nie zaobserwowałem) ale będę wiedział czy faktycznie żaden bajt nie został pominięty. A finalnie pewnie dodam bufory na liniach karty. :)

Skoro nie masz tego problemu juz dziś, to widać karta nie robi problemu z odczytem nadmiarowych (z jej punktu widzenia) bajtów.

Jakas suma kontrolna by się niewątpliwie przydała.

Ee, warto to? Po co Ci ten CP/M ? Chcesz Turbo Pascala 1.0 zobaczyc?

J.

Nie o to chodzi. Miałem na myśli zliczanie bajtów odebranych po stronie komputera. Karta otrzymuje żądanie udostępnienia określonej liczby sektorów. Komputer ustawia wskaźnik początku bufora i pętli odczytuje flagi zajętości i dostępności danych udostępniane przez kartę. Jeśli dane są dostępne, pobiera je, zapisuje i inkrementuje wskaźnik bufora To karta w pewnym momencie pomija bajt i przeskakuje do przodu. Z punktu widzenia komputera wszystko nadal jest w porządku. Jeśli będę zliczał zapisywane bajty, to po fakcie będę mógł wiedzieć, czy faktycznie załadowała się całość. I na tej podstawie będe mógł podjąć decyzję: wykonać program czy wyprintować informację o błędzie.

Tak, chociaż to trochę skomplikuje mechanizm tworzenia obrazu, nagrywania go na kartę i ładowania do pamięci. Z drugiej strony mógłbym do tego wykorzystać początek partycji, oryginalnie wykorzystywany na bootloader. Oryginalnie komputer wczytywał stamtąd krótki programik, który mówił mu jak załadować resztę systemu z dysku. Mi to do niczego nie jest potrzebne, bo bootloader zapisany w EPROM-ie za jednym razem ładuje z pamięci całość danych i nie trzeba kombinować. Niemniej adresy nadal muszą być odpowiednio wyrównane, wiec ten fragment jest nieużywany. W przyszłości mógłbym tam zapisywać jakaś sumę kontrolną.

Chcę odpalić Zorka na PRL-owskim mikroprocesorze. ;)

No tak, ale jak karta przeskakuje 1 bajt, to tak jakby komputer chciał odczytac 1 bajt więcej. I widać nie ma z tym kłopotów, więc albo:

-wysłałes do karty żądanie odczytu większej ilosci sektorów, i oczekuje nadmiar na odczyt,

-karta automatycznie udostępnia kolejne sektory,

-jakis timeout mas w bootloaderze, i nawet nie zauważa, ze 1 bajtu zabrakło,

-gdzie indziej leży problem, w procesorze/bootloaderze ... przerwania np ?

-karta jakas taka, że sama wewnętrznie przeskakuje ten 1 bajt, i potem uzupełnia ... IMO, mało prawdopodobne ...

Albo ostatnie bajty obrazu. Przygotujesz obraz, przepuscisz przez program generujący sumę kontrolne, zapisze w pliku, a potem plik zapiszesz na kartę.

Są symulatory. A moze nawet jest port.

Przecież CP/M nie miał grafiki, to tekstowa gra ?

J.

Wydaje mi się, że karta po prostu uznaje ten jeden bajt za wysłany. Tak wynikałoby z tego posta, który wczoraj znalazłem i przytaczałem. Kwestia zakłóceń na magistrali przy szybko zmieniających się stanach linii. Względnie nowoczesna, szybka karta jest na to znacznie bardziej wyczulona niż stary procesor. Do tej hipotezy zdaje się też pasować fakt, że najwyraźniej niektóre karty są wolne od tego problemu. A komputerowi wszystko jedno, bo to nie on steruje procesem. Nie ma tam żadnej pętli, w której oczekiwałby określonej liczby bajtów. On po prostu prosi kartę o wysłanie odpowiedniej liczy sektorów zaczynając od określonego punktu startowego, a potem przyjmuje dane tak długo, jak ustawiane są odpowiednie flagi.

Jak wynika z kodu który wrzuciłem, proszę o 32 sektory (16kB).

Timeoutu nie ma, bo tak naprawdę nie jest potrzebny. Jeśli komputer zawiesi się na tym etapie, to tak naprawdę jedynym wyjściem będzie reset całego systemu. Przerwania w tym konkretnym momencie są wyłączone na poziomie procesora (instrukcja DI). Karta nie może tak po prostu wysłać o jeden lub kilka bajtów za mało w losowych miejscach, bo prosimy ją o wysłanie danych liczonych w sektorach (po 512 bajtów). Dlatego najbardziej prawdopodobna wydaje się hipoteza mówiaca, że bajt "przeskakuje" ponieważ karta uznaje, że bajt został już wysłany (kiedy tak naprawdę nie miało to jeszcze miejsca) i przechodzi do wysyłania kolejnego.

Właśnie to jest najbardziej prawdopodobne wyjaśnienie, pasujące do tego, co wrzuciłem wczoraj. Ktoś miał bardzo podobny objaw i mają za niego odpowiadać zakłócenia na magistrali, na które wrażliwe są szybkie karty. Lekarstwem jest użycie buforów albo gorszej karty. Karta niczego nie musi uzupełniać, bo z jej punktu widzenia została nadana właściwa liczba danych. Tymczasem komputer nigdy nie otrzymuje (co najmniej) jednego bajtu, a więc nie inkrementuje wskaźnika i kolejny nadawany przez kartę trafia na jego miejsce w pamięci.

Przy czym tak naprawdę niewiele mnie to ratuje. Tak - będę w stanie wykryć niepoprawne załadowanie systemu, jednak jeśli transmisje między kartą CF i pamięcią/procesorem nie będą poprawne, to system wykrzaczy się zaraz później, na ładowaniu programów i operacjach na plikach. Bo tam raczej nie będzie żadnych sum kontrolnych...

Oczywiście, że są. Tylko co do za przyjemność? ;) Wiesz, ja kolekcjonuję stary sprzęt. Jeśli mogę, to w oryginale, jeśli nie to w formie współczesnego klona. I właśnie ta "epoka" to jest trochę taka dziura w kolekcji, bo w Polsce nie mieliśmy amatorskich komputerów tej generacji. MCY7880 pracował głównie w sprzęcie produkowanym na potrzeby instytucji państwowych. Nie mieliśmy naszego ALTAIR-a 8800 albo IMSAI 8080. Amatorska Cobra pojawiła się nieco później i była już na Z80. A że parę lat temu wpadło mi w ręce kilka sztuk MCY7880 z peryferiami (i dodatkowo w szufladach miałem sporo scalaków od CEMI) pomyślałem, że zrobię z tego działający system z użyciem polskich części. ;)

Tak. Tekstowa przygodówka. Żeby było ciekawiej wersja prototypowa posiada nieco anachroniczny układ wideo TMS9918. Teoretycznie może on generować grafikę (ma sprzętowa obsługe sprite'ów) jednak w moim projekcie pracuje tylko w trybie tekstowym. Wersja finalna dostanie już raczej jakiś bardziej typowy dla epoki, czysto graficzny kontroler wideo. Zaletą TMS-a była łatwa implementacja wynikająca z tego, że posiada on własną pamięć wideo na osobnej magistrali, dlatego trafił do wersji prototypowej. Gdzieś kiedyś czytałem, że ponoć niektóre systemy na CP/M można było wyposażyć w kartę graficzna na TMS99xx i po zastosowaniu jakiejś programowej warstwy kompatybilności dało się odpalać gry z jakiejś platformy opartej na Z80 i TMS99xx (MSX? Sega?), jednak u mnie to odpada, bo nie mam procesora Z80. Cała frajda tego projektu wiąże się z faktem, że został w nim użyty rodzimy klon 8080 + cała masa części polskiej produkcji. ;)

Innym anachronizmem w projekcie jest pecetowy kontroler klawiatury, jednak dzięki temu nie musiałem się bawić z budowaniem własnej - komputer działa z klasyczną klawiaturą AT/PS2.

No. To na koniec komputer chce od niej o 1 bajt za dużo.

spodziewałem się, ze w bootloaderze masz czytanie określonej liczby bajtów, ale widzę, że nie.

Czytanie na flagi znów rodzi kwestię zależnosci czasowych, ale karta raczej szybka, a 8080 bardzo wolny. A zgubić tak drugi bajt byłoby raczej trudno.

Może i tak, ale w tym CFWAIT jakos czekasz, może byc za mało lub za dużo. Ale patrzę w program - jak przerwie, to całość, drugiego bajtu tak nie zgubisz.

nie pamietam ... chyba były jeszcze niemaskowane, czy to dopiero w Z80 ?

Ciekawie byłoby zobaczyc ile bajtów bootloader przeczytał.

Zakładałem, ze BL odczytuje założoną ilość bajtów. I wtedy karta musiałaby uzupełnić ilość.

Ogólnie racja, ale takie zabezpieczenie jest sensowne, żebyś był pewny, że uruchamiasz dobry program.

Inaczej ... wszytko tam może być, przypadkowe dane, które się stają przypadkowym programem, czy lekko przekłamany program, który cos uszkodzi, albo np skasuje kartę ...

Nie widzę przyjemnosci w starej grze tekstowej. No ale wiadomo - de gustibus ...

IMO - no i dobrze, jesli Z80 lepszy. A pojawił się raptem 2 lata po

był jeszcze 8085 - taki trochę lepszy 8080.

No coż, de gustibus ... Takie komputerki były za PRL, ale raczej przemysłowe ... i chyba nikt nie patrzył na polskość, tylko na stawiane wymogi - jak były potrzebne zagraniczne kości, to się kupowało.

Wsadzic mogłeś duzo, ale standard nie przewidywał, to i z programami gorzej. Akurat w CP/M szybko zaczęło brakować pamięci, to pewnie był nacisk, aby pamięc video jakoś bankować.

Podejrzewam MSX, ale lista komputerków z tym systemem jest dłuzsza.

Niech Ci będzie :-)

J.

To ja bym jeszcze sprawdził, czy FF w innych miejscach też bywają pomijane.

Ale to troche dziwne. Bo niby takie FF mogłoby zakłócic inne linie, ale czekasz w programie ten CFWAIT, czytasz CFREG7, odczytujesz CFREG0 ... i co by tu się musiało stać, żeby karta bajt zgubiła?

Jakies zakłocenie na linii CS/IORD czy co tam jest używane? Nie wiem, czy karta by zdążyła, bo procesor wystawia IORD i wkrótce zatrzaskuje dane. Raczej bym się spodziewał, ze zgubi wtedy trzeci bajt.

Chyba, ze problem sie zdarza przy odczycie pierwszego bajtu, procek odczytuje poprawnie, ale karta widzi jakis kolejny odczyt, który idzie w próżnie. Ale w pierwszym bajcie 21h.

Akurat stan wysoki to ma raczej mniejsze prądy w TTL, ale raczej nie na wejsciach NMOS.

Jeśli to coś związane z prądami na liniach danych, to moze połącz solidniej masy karty, zasilanie, i dodaj kondensatorów przy gnieździe ..

Oscyloskop też byłby ciekawy, ale tu raczej jakis cyfrowy potrzebny, aby złapać odczyt tego jednego bajtu ...

J.

Chyba na wyjaśnienie wskazuje znaleziony w Internecie opis podobnej sytuacji, który przytaczałem wczoraj:

"When the eight data lines of a fast CF disk simultaneously drive capacitive loads such as a backplane with many boards, especially from all 0's to all 1's, a large instaneous current is flowing out of the CF disk, which cause its ground to sink lower than the system reference ground. The ground negative spike is too brief to affect Z80 and older TTL technology, but the CF_read line see a brief positive spike when CF's ground is spiking down. The CF_read controls a FIFO, so a spike can cause the FIFO to advance to next data byte thus discarding current byte of data thus corrupt the data packet."

Kondensatory przy zasilaniu karty są już obecne (100nF + tantal kilkadziesiąt uF). Zastanawia mnie jeszcze tylko zasilanie. VDD i VSS idą liniami taśmy, która łączy moduł karty CF z płyta główną. Może to za mało? Może powinienem pociągnąć masę i 5V osobnymi przewodami, gdzieś z okolicy bliższej zasilaczowi?

Nie jestem przekonany. prąd płynie od + zasilacza, przez +V karty, przez linie sygnałowe, do masy gdzies na płycie komputera, i do - zasilacza. Masa karty nie gra tu roli. A gdzie podłączona masa karty? nie wiadomo. Płytkę masz 2 warstwową, czy 4?

Hm ... a jednak nie tak prosto. Bo ten prąd nie płynie z zasilacza, tylko z kondensatora na karcie. I wraca do - kondensatora. Ale w którą stronę bedzie impuls napięcia ?

Hm, musialbym odszukac wykresy.

Strona 9 - odczyt portu jest cyklu M3. DBIN, który jak rozumiem jest zamieniany na IORD, jest aktywany w podcyklu T2, a dane są zatrzaskiwanie na początku T3 - mało czasu, kruca bomba..

A karty CF to nie wiem jakie szybkie, potrafia tak szybko przeskoczyc, czy nie bardzo?

Raczej połączylbym masę okolic procesora z masą karty, jeśli jest taka możliwość.

J.

Prawdę mówiąc już nie pamiętam, ale wydaje mi się, że nie. W każdym razie u mnie system przerwań opiera się na kontrolerze 8259 i używam go do asynchronicznego odczytywania niektórych peryferiów. Po wykonaniu instrukcji DI te przerwania przestają przychodzić.

Tak, wiem. Jednych i drugich mam trochę w podręcznym zapasie i nawet chodziło mi po głowie, żeby za jakiś czas zrobić też system oparty na Z80 i 8085. Byłoby o tyle łatwiej, że moje konstrukcje są modułowe, więc wystarczyłoby przygotować kompatybilną płytę procesorowa i połączyć ją z istniejącymi peryferiami. W ten sposób wcześniej udało mi się dość łatwo zrobić komputerek na MC6802, opierając się na istniejącej konstrukcji z MOS6502 (a jako niedokończony projekt zacząłem też robi płytkę pod MC68008).

Tyle tylko, że istniejących projektów pod Z80 albo 8085 jest całe mnóstwo, bo są to systemy relatywnie łatwe w implementacji. Intel 8080 odstrasza takimi szczegółami jak trzy napięcia zasilania, dwufazowy zegar albo konieczność użycia osobnego kontrolera magistrali.

Był przemysłowy komputer MSA80 i pewnie trochę mniej skomplikowanych sterowników mikroprocesorowych do automatyki. Jednak były też komputery ogólnego przeznaczenia, jak Elwro 500, Elwro

Jasne - sam standard CP/M przewiduje tylko drukowanie znaków na ekranie, jakby to był dalekopis. System nie zakłada nawet, że podpięty ekran jest inteligentnym terminalem, w którym można sterować kursorem. Nie ma więc gwarancji, że wszędzie zadziałają gry i programy wykorzystujące manipulowanie semigrafiką. A wszystkie operacje graficzne muszą już odwoływać się bezpośrednio do sprzętu, bo system nie przewiduje w ogóle takich standardowych wywołań.