Akcelerator graficzno-dźwiękowy do Spectrum

[smok.wawelski]

Zależy co chcesz osiągnąć.
Jeśli planujesz jedynie dwukierunkową komunikację na wybranym porcie (kolejnych portach), to mniej więcej właśnie tyle.
Jeśli chcesz sniffować szynę żeby śledzić zapisy do pamięci obrazu, powiedziałbym, że minimum 26.
Jeśli chcesz by RPi udawała równocześnie kilka urządzeń (klawiatura, myszka, joy, magnetofon, dźwięk) to zacząłbym liczyć od 28.
Jeśli chcesz przejąć szynę i modyfikować/czytać pamięć (pamiętaj o odświeżaniu i nie wchodź w paradę ULA!) przekroczysz 30.

Na początek komunikacja dwukierunkowa.
Potem mirror pamięci wideo.
Udawanie urządzeń - może - głównie jako zamiennik divide.

Czy sądzisz, że jestem w stanie to osiągnąć bez dodatkowego układu, korzystając tylko z pinów RPi czy w ogóle to mrzonka? Nie chodzi mi o oszczędności ale gdyby dało się spiąć oba urządzenia bez dodatkowego hardwaru, to każdy właściciel RPi mógłby sobie coś takiego zmontować na płytce stykowej.

[steev]

Na początek komunikacja dwukierunkowa.
Potem mirror pamięci wideo.
Udawanie urządzeń - może - głównie jako zamiennik divide.

Czy sądzisz, że jestem w stanie to osiągnąć bez dodatkowego układu, korzystając tylko z pinów RPi czy w ogóle to mrzonka? Nie chodzi mi o oszczędności ale gdyby dało się spiąć oba urządzenia bez dodatkowego hardwaru, to każdy właściciel RPi mógłby sobie coś takiego zmontować na płytce stykowej.

Gdybym miał gdybać, to powiedziałbym, że do komunikacji dwukierunkowej wystarczy ci level shifter (ale raczej scalony, nie na rezystorkach)
Oczywiście zakładając że Pi się wyrobi czasowo i nie ominie jakiegoś zapisu/odczytu.
Mirror i pozostałe - oprócz dopasowania poziomów będą wymagać co najmniej jednego scalaka wspierającego dekodowanie adresów.
(a może jednak CPLD? załatwi i dopasowanie, i dekoder adresów, i bufor danych dla Pi... )

[smok.wawelski]

Podejrzewałem, że level shifter będzie potrzebny i to dwukierunkowy... na szczęście to tania sprawa ale automatycznie oznacza zrobienie płytki.
Problemem będzie synchronizacja czasowa RPi, chyba że zamiast Linuxa całość będzie działać bez systemu (co rodzi inne problemy ale już softwarowe,  np. brak akceleracji sprzętowej grafiki itp.)
Jeśli Linux - zdecydowanie musi być bufor na dane (zarówno przy mirrorowaniu jak i przy komunikacji).

Dzięki wielkie za pomoc.

[smok.wawelski]

Projekt posuwa się do przodu. Na ten moment gotowy jest soft po stronie klienta (obecnie to PC), które dekoduje obraz ZX (.scr) i potrafi go wyświetlić (różne opcje skalowania, sztucznego interlace'u i antyaliasingu). Jeśli udałoby się poprawnie zaimplementować podsłuchiwanie pamięci, to przy okazji powstałby dość tani (aczkolwiek wymagający komputera lub RPI) konwerter HDMI do wyświetlenia zawartości ekranu ZX w oknie na PC lub na TV/monitorze.

Obecnie korzystam z Teensy 3.1 do podsłuchiwania szyny ZX Spectrum i pojawił się problem. O ile wydaje mi się, że sygnały RD/WR i MEMREQ odkodowuję poprawnie, o tyle po odczytaniu szyny adresowej dostaję bzdury, a raczej nie to, czego się spodziewałem.

Przykładowo, po uruchomieniu programu BASIC, który POKEuje adres 16384 nigdy nie widzę go po odkodowaniu szyny adresowej przy niskim sygnale WR i MEMREQ. Teensy działa z taktowaniem 96Mhz więc (teoretycznie) powinno się wyrobić z odkodowaniem adresu, w trakcie kiedy Z80 próbuje zapisać dane.

Szynę odkodowuję zgodnie ze algorytmem: A0-bit najmniej istotny, bit A15 << 15. Co może iść nie tak? ZX podczas "jałowej" pracy - czyli uruchomiony kursor BASICa wygląda jakby próbował pisać w wysokie adresy RAM (45-60 KB), nie wykrywam poprawnie zapisu do pamięci video podczas komendy CLS i tak dalej, widzę zapisy do obszaru adresowego ROMu co jest już chyba całkiem bez sensu. Pomyślałem, że może część z tych zapisów to obsługa IO, więc dodałem detekcję IOREQ ale nie poprawiło niczego.

Jedyny pomysł jaki mam na ten moment (po wielu próbach) to ustawianie niskiego stanu WAIT podczas dekodowania adresu (może część bitów zdąży się zmienić podczas odczytywania pinów?)

A może jest prostszy sposób odczytywania pamięci bez konieczności ciasnego dopasowania timingów bezpośrednio z układów pamięci?

[Phonex]

ZX podczas "jałowej" pracy - czyli uruchomiony kursor BASICa wygląda jakby próbował pisać w wysokie adresy RAM (45-60 KB) ..

Może to zapis na stosie? Stos po resecie standardowo jest pod 65xxx.

[smok.wawelski]

Zapis na stosie nie tłumaczy braku zapisów pod adresy video RAMu . W każdym razie dzięki za wskazówkę.

[pear]

Może to ULA zakłóca przebiegi (floating bus). Te zapisy do video RAM, to może być odświeżanie przez ULA.

[trojacek]

Pear, wybacz, ale się zgubiłem.
Smok.wawelski napisał, że w obrębie pamięci obrazu nie widać żadnej aktywności.
Poza tym cykl odświeżania nie jest raczej widoczny jako zapis.
Poza poza tym, ULA raczej nic nie odświeża, poza systematycznym siekaniem w pamięć cyklami odczytu?

[pear]

Nie doczytałem Ale ... Czy nie jest to tak, że na złączu widać tylko tą stronę szyny, która jest przypięta do procesora ?
Pamięć obrazu jest podłączona do ULA, a do procesora przez rezystory.

[trojacek]

I tak, i nie.
Bo gdyby było tak jak piszesz - procesor nie miałby dostępu do pamięci obrazu, a przecież ma (w 48K właśnie przez rezystory). Ale skoro Z80 jest w stanie odczytać pamięć obrazu poprzez rezystory (470 ohm), to elektronika podłączona do złącza krawędziowego też będzie mogła. Ma ona dokładnie ten sam "punkt widzenia", co CPU.
I tak właśnie działa np. interfejs Spectra.

[trojacek]

Obecnie korzystam z Teensy 3.1 do podsłuchiwania szyny ZX Spectrum i pojawił się problem.

A jaki soft masz zainstalowany? Rozumiem, że Teensy to po prostu MCU na USB i nic więcej.
Pewnie wiesz, że nie do wszystkich pinów możesz podłączać 5V?

Teensy działa z taktowaniem 96Mhz więc (teoretycznie) powinno się wyrobić z odkodowaniem adresu, w trakcie kiedy Z80 próbuje zapisać dane.

Z tego co widzę, to nie 96, a 72 MHz. I jest to zegar procesora - zakładam, że odczyt stanu wejścia wymaga co najmniej kilku komend w asemblerze, więc pojawia się duże ryzyko "przegapiania" istotnych danych.
Nie można tego triggerować np. zmianą sygnału MREQ? Teensy nie ma wejść przerwań?

Jedyny pomysł jaki mam na ten moment (po wielu próbach) to ustawianie niskiego stanu WAIT podczas dekodowania adresu (może część bitów zdąży się zmienić podczas odczytywania pinów?)

Niezły pomysł. Tylko, o ile mnie pamięć nie myli, przy zbyt długim WAIT zaczniesz tracić zawartość górnej pamięci RAM z powodu braku jej odświeżania

[smok.wawelski]

Dokładnie mówiąc, nie mam zapisu pod adres 16384 mimo, że tam robię POKE. CLS nie daje wyraźnego efektu w postaci setek zapisów do obszaru pamięci obrazu - chyba, że jednak nie nadążam z odczytaniem ale musiałbym "mijać" bardzo wiele cykli. Ciężko uwierzyć mając 96Mhz pod ręką.... Jak próbkuję sygnał CLK to widzę 00011100011100 czyli odczytuję jeden sygnał wielokrotnie (liczba powtórzeń przykładowa).

Sprawdzałem dwukrotnie czy podpiąłem prawidłowo sygnały - czy nie ma błędu, że A5 odczytuję jako A8 (czyli 2^7 zamiast do 2^4) i go nie znalazłem (ale pewnie sprawdzę jeszcze raz jak nie znajdę problemu gdzie indziej). Sprawdzałem każdy sygnał oddzielnie i każdy pin czasem jest 1 a czasem 0, co wyklucza brak połączenia.

PS. Przy okazji odpowiem Trojackowi:
Teensy to takie 32bitowe arduino, więc soft napisałem sam - generalnie jest to kilka digitalRead(pin). Używam zegara 72Mhz lub 96Mhz (overclock) ale podobne efekty mam przy ustawieniach na 24Mhz lub 48Mhz - brak zapisów w obszar video RAM.
Teensy ma możliwość triggerowania przerwania ale wtedy musi odłożyć wszystkie rejestry na stos, co również trwa. Ciasny polling pinów jest szybszy - więc jak tylko wykryję WR/MREQ == LOW, to od razu zczytuję A0-A15. Jak robię odwrotnie (tzn. odczytuję cały czas A0-A15) to efekty podobne.

RAM zacznie zanikać dopiero po 100ms WAIT jak wyczytałem z dokumentacji, to całe wieki dla Teensy

[trojacek]

Większość RAM ma cykl odświeżania 2 ms, więc w to 100 to raczej bym nie wierzył
Ale skoro nic sensownego nie możesz odczytać, to popełniasz jakiś błąd w metodzie, nie w detalach. Bo jednak od czasu do czasu coś powinno dać się złapać.
Ja bym zaczął łopatologicznie - podłączyłbym bramki pod MREQ, WR, A15 i A14, by uzyskać iloczyn logiczny (MREQ low, WR low, A15 low, A14 high). Tym iloczynem popędziłbym diodę LED

[trojacek]

Zrobiłem mały test. Wpiąłem analizator stanów pod linie MREQ, WR, A15 i A14.
Zapisy do pamięci pojawiają się cyklicznie - pewnie ze względu na migający kursor.
Próbkowanie - zaledwie 24 MHz...

Mały update: po dalszej analizie sczytanych analizatorem danych już wiem, że cykliczne zapisy do pamięci były po prostu uaktualnianiem zmiennej systemowej FRAMES. Regularnie co 20 milisekund. A zmienne siedzą w tej samej ćwiartce pamięci RAM, co obraz.

[smok.wawelski]

Wygląda na to, że Teensy się nie wyrabia mimo całej swojej szybkości. Prawdopodobnie zanim odczytam ostatni z 16 bitów zmienia się jego zawartość, stąd bzdurne wartości.
Przy odczycie tylko 2 pinów faktycznie zaczęło działać lepiej - tzn. widzę zapisy w poprawne adresy ale ewidentnie nie wyłapuję wszystkich. Znalazłem dwie metody na przyspieszenie całej operacji ale zaczynam powątpiewać czy uda mi się odczytywać wartości w odpowiednim tempie (w sumie 26 pinów)
W każdym razie wielkie dzięki za pomysły!