Wojny religijne: co jeszcze jest retro, czy FPGA to emulacja itp.

[Atlantis]

Rozumiem, że używanie współczesnych komponentów może się kłócić z wyobrażeniem retro, ale od tego się nie ucieknie - w monitorze masz zdecydowanie bardziej wydajny procesor niż Z80, użycie zwykłej karty SD lub CF zawierającej wewnątrz bardziej złożony komputer niż cały system Z80 w którym zostałby użyty,...

Wiem, ale jednak to jest dużo mniejsza granica. Karta CF sama w sobie jest urządzeniem mocno retro, które zostało projektowane w taki sposób, aby móc pracować na magistralach bardzo starych urządzeń.
Od strony użytkownika jest to czarna skrzynka. Czterdzieści lat temu takie urządzenia jak HDD, FDD czy nawet klawiatura też często były obsługiwane przez osobny mikrokontroler. Do 8242 przecież można podłączyć zewnętrzny EPROM i wykonać na nim własny kod, chociaż wewnętrzna pamięć programowana maską zawiera firmware do obsługi klawiatury.

Wszystko sprowadza się do tego, żeby przeskok nie był za duży. Jeśli buduję system na 8080 czy Z80 to raczej nie znajdę do niego oryginalnego dysku twardego z epoki. Zresztą nawet gdybym znalazł, to pewnie padłby po kilku tygodniach używania. Natomiast karta CF jest już dostatecznie blisko. Osobny linuksowy komputer emulujący pamięć masową byłby już przesadą, bo równie dobrze mógłbym na nim emulować całość systemu.

Generalnie jest kilka poziomów, których wolę się trzymać.
1. Najbardziej postawowy to ten, gdzie na poziomie architektury wszystko ma pozostawać jak najbliżej realiów epoki. Czyli procesor i układy peryferyjne mają postać fizycznych chipów. Możliwe są drobne odstępstwa dla wygody - jak właśnie użycie karty CF, układów CMOS, pamięci SRAM, przetwornicy impulsowej w zasilaczu albo programowalnych układów logicznych GAL. Jednak żadnych współczesnych mikrokontrolerów, CPLD czy FPGA. Tak wygląda większość moich autorskich konstrukcji, do tej kategorii łapią się też takie projekty jak Harlequin.
2. Mocno uwspółcześnione projekty, gdzie procesor nadal jest fizyczny ale spora część logiki jest odtworzona w jakimś CPLD/FPGA, a rolę pamięci masowej pełni karta SD. To nadal w sumie oryginalna architektura, ale mocno udoskonalona i czerpiąca ze współczesnych możliwości technologicznych. Nadal żadnych mikrokontrolerów, poza tymi, które i tak są obecne w "czarnych skrzynkach" (np. karcie SD).
3. Pójście na całość i zaimplementowanie wszystkiego w FPGA (np. ZX Uno). To nadal nie emulacja (bo logika jest zaimplementowana w krzemie, tylko programowalnym, a nie algorytmie wykonywanym na CPU), architektura pozostaje bliska oryginałowi, tylko wszystko jest zrobione na współczesnej technologii.

Problem zaczyna się dla mnie wtedy, gdy projekt zaczyna emulować fragmenty oryginalnego hardware'u w kawałkach softu wykonywanego na współczesnych mikrokontrolerach. Szczególnie, jeśli te mikrokontrolery równie dobrze mogłyby emulować całą maszynę - a to można powiedzieć o wszystkich Raspberry Pi, czy nawet "małych" ARM-ach albo ESP32.

Dlatego mogąc wykorzystać oryginalny sterownik klawiatury i monitora, będę je preferował.

[tapy]

Czym się różni logika zrealizowana na FPGA od procesora? W obu przypadkach masz kod ładujący, macierz bramek czy cpu, ta różnica staje się bardzo płynna. Często współczesne mikrokontrolery posiadają już elementy FPGA. Czarna skrzynka ESP32 i karty CF jest tak samo skomplikowana, jedyną różnicą jest że jeden system realizuje konkretne zadanie a drugi jest uniwersalny. Potraktuj metalową puszkę ESP tak samo jak puszkę karty CF
ZX Unu to jednak emulator, algorytm wykonuje macierz bramek, zaprogramowanych językiem wysokiego poziomu. Myślę że C i VHDL jest tak samo dalekie od naszych 8-bitów.

[Atlantis]

Czym się różni logika zrealizowana na FPGA od procesora?

Różnica jest zasadnicza. W przypadku CPLD/FPGA masz macierz fizycznych bloków logicznych, istniejących w krzemie. Programujesz połączenia między nimi. Jest to więc relatywnie bliską operacją do fizycznego odtworzenia jakiegoś układu z układów scalonych. Z tą różnicą, że dzieje się to od nowa za każdym razem po włączeniu zasilania. Do tego masz główną zaletę realizacji jakiegoś zadania w fizycznym układzie logicznym - poszczególne operacje wykonują się równolegle, w miarę propagacji sygnałów.
W przypadku CPU tworzona jest programowa reprezentacja oryginalnego sprzętu. Bloki logiczne nie istnieją fizycznie w krzemie, a jedynie są reprezentowany jako abstrakty w pamięci, obsługiwane przez algorytm wykonywany na procesorze. A ponieważ (jednordzeniowy) procesor potrafi naraz robić tylko jedną rzecz, musisz dysponować znacznie szybszym taktowaniem, aby stworzyć pozory, że wszystkie te wirtualne bloki realizują swoje zadanie na czas. A i tak często spełnienie wszystkich delikatnych zależności czasowych jest wielkim problemem.

W obu przypadkach masz kod ładujący, macierz bramek czy cpu, ta różnica staje się bardzo płynna.

Właściwie tutaj podobieństwo się zaczyna i kończy. Bo w FPGA masz kod ładujący na początku, potem (po skonfigurowaniu) taki układ działa już jak normalna konstrukcja z układów logicznych. Emulator na CPU działa w oparciu o sekwencje instrukcji, próbujące naśladować mechanikę oryginalnego sprzętu.

Często współczesne mikrokontrolery posiadają już elementy FPGA.

Tak, ale należy je traktować jako dodatkowe (programowalne) peryferium. Nie znaczy to, że można pomiędzy tymi dwiema rzeczami postawić znak równości.

Czarna skrzynka ESP32 i karty CF jest tak samo skomplikowana, jedyną różnicą jest że jeden system realizuje konkretne zadanie a drugi jest uniwersalny. Potraktuj metalową puszkę ESP tak samo jak puszkę karty CF

Karta CF jest czarną skrzynką w tym sensie, że nie mogę jej programować. A przynajmniej nie w łatwy sposób. Jest to po prostu pudełko przyjmujące sygnały na wejściu i zwracające odpowiednie sygnały na wyjściu. Do tego robi to w taki sam sposób, jak stare dyski twarde.  I tak- wiem, że jest to mocno subiektywne odczucie, jednak po prostu emulowanie sporego kawałka oryginalnego sprzętu w sofcie odpalonym na współczesnym MCU ma tyle samo wspólnego z retro co emulowanie całości - fajny i wygodny sposób na uruchomienie starego softu, ale trudno mówić w tym przypadku o technice retro.

ZX Unu to jednak emulator, algorytm wykonuje macierz bramek, zaprogramowanych językiem wysokiego poziomu. Myślę że C i VHDL jest tak samo dalekie od naszych 8-bitów.

W żadnym wypadku. W przypadku VHDL-a nie masz algorytmu. Masz opis zadania realizowanego sprzętowo, za pomocą układu z elementów logicznych. Jest to jedną z podstawowych rzeczy, do jakich trzeba się przyzwyczaić ucząc się VHDL-a czy Veriloga - pisany kod nie jest sekwencją instrukcji uruchamianych po sobie, ale opisem struktury. Zależności które tam opiszemy będą zachodziły równolegle, z uwzględnieniem czasów propagacji. Taki kod można spokojnie przetłumaczyć na schemat złożony z bramek i może on służyć jako punkt wyjścia do prototypowania układów ASIC. Nie 1:1, bo występują istotne różnice technologiczne, ale pierwszym etapem przy projektowaniu cyfrowego ASIC-a często jest właśnie zaimplementowanie tego w VHDL-u albo Verilogu.
FPGA nie ma wiele wspólnego z programową emulacją. Ma za to wiele wspólnego z technologią w jakie były produkowane takie układy jak ULA do ZX Spectrum czy ZX81. Tam krzemowa struktura zawierała określony zestaw uniwersalnych bramek. Potem na taką strukturę nanoszono maskę z połączeniami, odpowiadającymi potrzebom konkretnego odbiorcy. W przypadku FPGA różnica jest taka, że te połączenia są konfigurowalne za każdym razem przy starcie układu.

[tapy]

W kwestii FPGA, mam inne zdanie, to emulacja, bo załadowanie wsadu czyni ten układ Z80, by za chwilę, po jego zmianie stał się np. 6502. Dokładnie tak samo jak bym to zrobił na współczesnym CPU, inny plik z dysku i mam nowy emulator.

I to jest właśnie subiektywna ocena czym jest retro, jedni uważają że komputer w karcie CF jest OK, inni już widzą w tym wydajny system przewyższający swoją mocą obliczeniową dowolny 8-bitowy sprzęt retro.

[Atlantis]

W kwestii FPGA, mam inne zdanie, to emulacja, bo załadowanie wsadu czyni ten układ Z80, by za chwilę, po jego zmianie stał się np. 6502. Dokładnie tak samo jak bym to zrobił na współczesnym CPU, inny plik z dysku i mam nowy emulator.

Tyle tylko, że tutaj jest jedna, zasadnicza różnica. Układy FPGA wyewoluowały z układów takich jak ULA, gdzie produkcja składała się z dwóch etapów: najpierw tworzyło się krzemową płytkę z uniwersalnym zestawem bramek, a potem nanosiło się na tę płytkę połączenia w zależności od tego, co było potrzebne odbiorcy. Układ był programowalny, ale jednorazowo i to na etapie produkcji.
Potem powstały podobne układy, których programowanie polegało na jednorazowym przepalaniu niepotrzebnych połączeń - układ można było zaprogramować tylko raz, dysponując odpowiednim sprzętem, ale nie musiało się to odbywać na etapie procesu produkcyjnego. W końcu zaczęły powstawać coraz bardziej skomplikowane układy GAL/PAL/CPLD, w których połączenia można było wielokrotnie przestawiać elektrycznie, w oparciu o konfigurację zapisaną w pamięci flash. Ta pamięć zawiera tylko tę konfigurację, a nie żaden wykonywany program - nie można więc mówić o emulacji. To znaczy inaczej - oczywiście pamięć może zawierać także i program, który uruchomimy CPU zbudowanym z bramek wewnątrz FPGA, ale wcale nie musi.
Współczesne układy FPGA różnią się tylko tym, że są (dużo) większe i niekiedy pozwalają na dokonywanie rekonfiguracji podczas działania.

Programowa emulacja polega na czymś zupełnie innym - to proces, w którym oryginalny hardware jest odwzorowywany jako soft wykonywany na procesorze. To jest co najmniej kilka warstw abstrakcji wyżej. W przypadku FPGA masz po prostu załadowanie konfiguracji z pamięci, która tworzy tymczasową, ale jak najbardziej sprzętową instancję danej architektury. W przypadku emulacji masz programowe odwzorowanie, obsługiwane przez jakiś zestaw bibliotek, działających na jakimś systemie operacyjnym, uruchomionym na jakimś procesorze. To nie jest kwestia subiektywnej interpretacji. To są obiektywne fakty. Te słowa mają dość konkretne znaczenia.

[tapy]

Jak wspominałem wcześniej, każdy ma swoje indywidualne podejście do tego tematu, ja nie zmienię Twojego, a Ty mojego. Ja dopuszczam użycie jako peryferii układów CPU i FPGA, ale użycie ich jako procesor kłóci się z moim wyobrażeniem retro, emulacja namiarowymi bramkami przy równoległej emulacji lub nadmiarowym zegarem przy sekwencyjnym pozostanie dla mnie tym o czym pisałem.

Wracając do tematu wątku jestem w trakcie opracowywania aktywnego backplane RCBus (5 slotów+slot rozszerzenia), który będzie zaopatrzony w przetwornicę step-down MP1584, układ supervisora TL7705 oraz konwertera serial-usb CH340E. Chwilowo utknąłem na problemie dystrybucji zasilania (zasilanie od strony USB i/lub zewnętrznego zasilacza) co może się skończyć dodaniem jeszcze jednego układu, ale to wyjdzie w praniu.

PS. Wczoraj została wydana pierwsza wersja specyfikacji RCBus, zawierająca obsługę Z80 (niepełna niestety), 68xx i 65xx, w załączniku dokumenty.

[Atlantis]

Jak wspominałem wcześniej, każdy ma swoje indywidualne podejście do tego tematu, ja nie zmienię Twojego, a Ty mojego. Ja dopuszczam użycie jako peryferii układów CPU i FPGA, ale użycie ich jako procesor kłóci się z moim wyobrażeniem retro, emulacja namiarowymi bramkami przy równoległej emulacji lub nadmiarowym zegarem przy sekwencyjnym pozostanie dla mnie tym o czym pisałem.

Wydaje mi się, że w pewnym momencie zaczęliśmy mówić o dwóch różnych kwestiach. Dyskusja zaczęła się od tego, jakie (w miarę) współczesne rozwiązania są dopuszczalne w rekonstrukcjach urządzeń retro, żeby wciąż można było uznać je za "zgodne z klimatem retro". I tutaj mamy do czynienia ze spektrum - po jednej stronie mamy budowę repliki Apple One w oparciu o oryginalne, nieprodukowane od lat siedemdziesiątych części, kosztujące na eBay'u nawet po kilkaset dolarów. Po drodze ludzie będą decydować się na kompromisy: układy CMOS zamiast TTL/LS, zastąpienie części logiki przez GAL/CPLD/FPGA, użycie przetwornicy impulsowej zamiast stabilizatora liniowego. Na końcu tego spektrum znajduje się programowa emulacja na współczesnych komputerach. I tutaj faktycznie każdy sam sobie wybiera co jest zgodne z tym, co postrzega jako "klimat retro". Ja mam w tym zakresie dość ostre restrykcje.

Potem zaczęliśmy mówić o FPGA i emulacji. I tutaj już zaczynamy dyskusję o faktach, a nie odczuciach. FPGA to nie emulacja. Oczywiście możesz mówić, że jest inaczej, ale wówczas będziesz w błędzie. Emulacja odnosi się do odwzorowywania zachowania oryginalnego systemu przez sofware'owy algorytm. FPGA odtwarza oryginalną architekturę w konfigurowalnej macierzy krzemowych bloków logicznych. Dwie zupełnie różne sprawy, dwa zupełnie różne podejścia, z których to drugie jest nieporównywalnie bliższe sprzętu. Ma też swoje zalety - w FPGA o wiele łatwiej odtworzyć oryginalne zależności czasowe, co przekłada się na stopień kompatybilności z oryginałem.
Ta różnica jest też dość dobrze widoczna z punktu widzenia programisty. Co prawda w VHDL-u jestem dopiero początkujący i robiłem na nim proste projekty (m.in. zegar do którego planuję dodać w przyszłości moduł synchronizacji przez DCF77) ale to wystarczyło, żeby poczuć różnicę. Proces pisania kodu pod CPLD/FPGA w dużo większym stopniu przypomina projektowanie urządzenia elektronicznego z układów TTL, niż pisanie sekwencyjnego kodu do wykonania na procesorze. Musisz się przestawić na zupełnie inny mindset.

Wracając do tematu wątku jestem w trakcie opracowywania aktywnego backplane RCBus (5 slotów+slot rozszerzenia), który będzie zaopatrzony w przetwornicę step-down MP1584, układ supervisora TL7705 oraz konwertera serial-usb CH340E. Chwilowo utknąłem na problemie dystrybucji zasilania (zasilanie od strony USB i/lub zewnętrznego zasilacza) co może się skończyć dodaniem jeszcze jednego układu, ale to wyjdzie w praniu.

Chętnie bym skorzystał z czegoś takiego. Dla mnie właśnie największym problemem w sporej części amatorskich konstrukcji jest zasilanie z okrągłej wtyczki 5V. Identyczne złącza dostarczające zasilanie o różnych napięciach i polaryzacjach od zawsze były zmorą świata retro. Łatwo mówić "uważaj co robisz", tylko ludzie tak nie działają. Wystarczy jedna chwila, kiedy jest się trochę bardziej zmęczonym albo zamyślonym i w wyniku podpięcia 9V zamiast 5V mamy zniszczone urządzenie. Takie sytuacje powinno się eliminować na etapie projektu, stosując gniazda unikalne dla określonego standardu zasilania (np. USB) albo obwody zasilania tolerujące szeroki zakres napięć i obydwie polaryzacje. Ja rozumiem, czterdzieści lat temu producenci chcieli oszczędzić, jednak jeśli dzisiaj budujemy urządzenie do którego części kosztują kilkaset zł, to nie wyobrażam sobie, żeby nie pomyśleć o takim zabezpieczeniu. Już parę razy kończyło się to tak, że po złożeniu płytki przyjmującej 5V (np. klon Cobry 1) wkładałem ją do obudowy z zewnętrzną przetwornica impulsową albo zasilaczem 230V. Dla świętego spokoju.

[trojacek]

Karta CF sama w sobie jest urządzeniem mocno retro

Karta CF pojawiła się na rynku w 1994 roku, więc jest mniej "retro", niż np. FPGA (1985 - pierwszy komercyjny model Xilinxa XC2064).

które zostało projektowane w taki sposób, aby móc pracować na magistralach bardzo starych urządzeń.

Nie - zostało zaprojektowane jako zgodne na poziomie logicznym z ówczesnym standardem dysków twardych, Parallel ATA, jednak z zastosowaniem nieco innego, znacznie mniejszego złącza. Miało to na celu przyszłą konwergencję standardów w przypadku miniaturyzacji dysków twardych, co ziściło się w postaci np. IBM Microdrive.

Do 8242 przecież można podłączyć zewnętrzny EPROM i wykonać na nim własny kod, chociaż wewnętrzna pamięć programowana maską zawiera firmware do obsługi klawiatury.

Jak chcesz podłączyć zewnętrzną pamięći do 8042/8242, nie mając szyny adresowej? Przez porty I/O (P1/P2)? Wtedy zawartość pamięci masz jako dane, a nie kod programu. Można oczywiście przepisać dane odczytane z I/O do wewnętrznej, malutkiej pamięci RAM (256 bajtów), tylko nie widzę w tym specjalnie sensu.

Natomiast karta CF jest już dostatecznie blisko. Osobny linuksowy komputer emulujący pamięć masową byłby już przesadą, bo równie dobrze mógłbym na nim emulować całość systemu.
(...)
Problem zaczyna się dla mnie wtedy, gdy projekt zaczyna emulować fragmenty oryginalnego hardware'u w kawałkach softu wykonywanego na współczesnych mikrokontrolerach. Szczególnie, jeśli te mikrokontrolery równie dobrze mogłyby emulować całą maszynę - a to można powiedzieć o wszystkich Raspberry Pi, czy nawet "małych" ARM-ach albo ESP32.

Dokładnie tak. Podobnie nie podchodzi mi stosowanie Raspberry Pi tylko po to, by mieć wyjście HDMI. To już niech na tym Raspberry chodzi emulator całości, niby po co w tym czasie grzać 40-letniego kompa?

Generalnie jest kilka poziomów, których wolę się trzymać.
1. Najbardziej postawowy (...)

My favourite.

2. Mocno uwspółcześnione projekty, gdzie procesor nadal jest fizyczny (...)

Czyli kompromis między sercem a rozumem
Bo tak naprawdę to już niewielka różnica (między tym a punktem 3) - skoro w 48K cała logika została zamknięta w nowocześniejszym chipie, i można tam jeszcze dorzucić procesor, bez przycinania funkcjonalności (złącze krawędziowe!), to co za różnica, czy ten Z80 będzie fizyczny, czy emulowany? To raczej właśnie podejście emocjonalne, że procesor, czyli serce komputera, powinien być fizyczny, prawdziwy, grzać się  i śmierdzieć . I trochę się z tym zgadzam, bo w sumie całe retro to bardziej serce niż rozum

W przypadku VHDL-a nie masz algorytmu. Masz opis zadania realizowanego sprzętowo

...i opis zadania to jest właśnie algorytm!

Algorytm – skończony ciąg jasno zdefiniowanych czynności koniecznych do wykonania pewnego rodzaju zadań, sposób postępowania prowadzący do rozwiązania problemu.

(https://pl.wikipedia.org/wiki/Algorytm)

Z sobie tylko znanych powodów (tzn. w celu udowodnienia swojej tezy) przycinasz definicję algorytmu do tego, co się będzie finalnie wykonywać na procesorze. Natomiast języki opisu sprzętu (VHDL, Verilog) są jak najbardziej algorytmami, ciągiem jasno zdefiniowanych czynności koniecznych do wykonania pewnego rodzaju zadań - a konkretnie, kolejnych faz przygotowania wsadu (core) dla układu programowalnego.

Taki kod można spokojnie przetłumaczyć na schemat złożony z bramek i może on służyć jako punkt wyjścia do prototypowania układów ASIC. Nie 1:1, bo występują istotne różnice technologiczne, ale pierwszym etapem przy projektowaniu cyfrowego ASIC-a często jest właśnie zaimplementowanie tego w VHDL-u albo Verilogu.

Bo generalnie FPGA powstał do prototypowania. To, że się ostatnio upowszechnił do innych zastosowań, wynika z sumarycznych kosztów procesu, które zostały znacznie zredukowane.
By zaprogramować pierwszy FPGA (XC2064), trzeba było zapłacić 12 tys. dolarów za samo oprogramowanie (pod DOS).

FPGA nie ma wiele wspólnego z programową emulacją.

Z programową - faktycznie nie.
Za to ze sprzętową - bardzo dużo. FPGA realizuje dokładnie to, co się potocznie nazywa hardware emulation. Bo nie ma tu żadnego fizycznego odwzorowania w krzemie, tylko jego udawanie poprzez sterowanie stanami logicznymi przez warstwę konfiguracyjną.

Ma za to wiele wspólnego z technologią w jakie były produkowane takie układy jak ULA do ZX Spectrum czy ZX81.

FPGA powstało jako funkcjonalna alternatywa dla ULA. A technologicznie różnią się bardzo, bo ULA ZX Spectrum jest strukturą bipolarną, a FPGA (nawet te pierwsze) to CMOS z tranzystorami NMOS i PMOS.

Tam krzemowa struktura zawierała określony zestaw uniwersalnych bramek. Potem na taką strukturę nanoszono maskę z połączeniami, odpowiadającymi potrzebom konkretnego odbiorcy. W przypadku FPGA różnica jest taka, że te połączenia są konfigurowalne za każdym razem przy starcie układu.

I z tego wynika podstawowa, funkcjonalna różnica: ULA była "kończona" przez producenta, a FPGA - przez użytkownika końcowego.

Wydaje mi się, że w pewnym momencie zaczęliśmy mówić o dwóch różnych kwestiach. Dyskusja zaczęła się od tego, jakie (w miarę) współczesne rozwiązania są dopuszczalne w rekonstrukcjach urządzeń retro, żeby wciąż można było uznać je za "zgodne z klimatem retro".

Ale to znowu dyskusja o uczuciach. Dla jednych retro to komputer w oryginalnym kartonie w szafie za szkłem, a z kolei druga skrajność to emulator ZX na smartfonie. Plus oczywiście ileś gradacji uczuć pomiędzy skrajnościami.
Sam używam emulatora na PC, ale tylko w kwestiach programistycznych (ot, czasami poklepię sobie trochę kodu), ale nie uważam, żebym wtedy siedział przy sprzęcie retro. Myślę, że podobnie by było, gdybym usiadł do Spectrum Nexta czy Uno. Ale nie siadam.
Z drugiej strony - mam ZX Spectrum 48K z ULA Plus, czyli supermałe FPGA dające nowe możliwości barwne. Retro, nie-retro?
Z trzeciej strony - moim peryferium numer 1 dla oryginalnych ZX jest divIDE. Scalaki z epoki (może poza flashem, ale można go zmienić na zwykły EPROM), no ale karta CF! Czyli już lata 90-te. Ale zwycięża wygoda, na pewno nie będę się szarpał z taśmami, a nawet kasetkami MD, jak zachce mi się w coś pograć. Z kolei FDD3000 zajmuje za dużo miejsca i wyciągam tylko na specjalne okazje (kurczę, muszę w końcu zmontować tego FDD35...).

Potem zaczęliśmy mówić o FPGA i emulacji. I tutaj już zaczynamy dyskusję o faktach, a nie odczuciach. FPGA to nie emulacja. Oczywiście możesz mówić, że jest inaczej, ale wówczas będziesz w błędzie.

No i tu skierowałeś dyskusję na swoje swoich osobiste odczucia, a nie fakty. W dodatku podnosisz temperaturę dyskursu stawiając się w roli jedynego nieomylnego, nie popierając tego niczym, poza własnymi odczuciami.
I oczywiście najprościej jest odbić piłeczkę - FPGA to jest emulacja. Oczywiście możesz mówić, że jest inaczej, ale wówczas będziesz w błędzie.

hardware emulation is the process of imitating the behavior of one or more pieces of hardware (typically a system under design) with another piece of hardware, typically a special purpose emulation system. The emulation model is usually based on a hardware description language (e.g. Verilog) source code

(https://en.wikipedia.org/wiki/Hardware_emulation)

Dalej jest konkretnie o zaletach stosowania FPGA, polecam cały ten wpis.

[tapy]

Dorzucę jeszcze jeden temat do przemyśleń - odpowiednio duży EPROM, zatrzask i mamy działający Z80
(uprościłem, w filmie jest odpowiedź) - https://www.youtube.com/watch?v=kfMMjk288co

[Atlantis]

Nie - zostało zaprojektowane jako zgodne na poziomie logicznym z ówczesnym standardem dysków twardych, Parallel ATA, jednak z zastosowaniem nieco innego, znacznie mniejszego złącza. Miało to na celu przyszłą konwergencję standardów w przypadku miniaturyzacji dysków twardych, co ziściło się w postaci np. IBM Microdrive.

Tak, ale jednocześnie karta CF potrafi pracować także w trybie ośmiobitowym, dzięki czemu może pracować właściwie bezpośrednio na magistrali procesora. Czasami trzeba tylko dodać bufor zapewniający odpowiednie poziomy logiczne.

Jak chcesz podłączyć zewnętrzną pamięći do 8042/8242, nie mając szyny adresowej? Przez porty I/O (P1/P2)? Wtedy zawartość pamięci masz jako dane, a nie kod programu. Można oczywiście przepisać dane odczytane z I/O do wewnętrznej, malutkiej pamięci RAM (256 bajtów), tylko nie widzę w tym specjalnie sensu.

Zobaczy tutaj. Projekt zegara oparty na 8042. Działa to podobnie jak w przypadku 8051 - możesz mu kazać zignorować wewnętrzną pamięć i pobierać kod z zewnętrznej magistrali. Wtedy porty robią za szynę adresową. Tracisz większość pinów, ale możesz to sobie zrekompensować dodając na magistrali dodatkowy port równoległy. To że 8042/8242 był wykorzystywany głownie jako sterownik klawiatury (i taki firmware wgrywano mu fabrycznie) nie zmienia faktu, że jest to normalny mikrokontroler, który można wykorzystywać w rozmaitych projektach.

Dokładnie tak. Podobnie nie podchodzi mi stosowanie Raspberry Pi tylko po to, by mieć wyjście HDMI. To już niech na tym Raspberry chodzi emulator całości, niby po co w tym czasie grzać 40-letniego kompa?

Mam podobne podejście, ale już np. karta graficzna z HDMI zrealizowana na FPGA mi nie przeszkadza dlatego, że to rozwiązanie jest zdecydowanie bliżej sprzętu. Nic lepszego nie dostaniemy do czasu, kiedy ktoś wymyśli sposób na małoseryjną produkcję układów scalonych na podstawie kodu VHDL/Verilog. Dzisiaj to brzmi jak fantazja, ale kiedy zaczynałem bawić się elektronika amatorską nikomu nie śniło się, że będzie można wysłać pliki do Chin i po paru tygodniach dostać kilka sztuk w pełni profesjonalnych płytek drukowanych. Za kilkanaście dolarów...

Czyli kompromis między sercem a rozumem
Bo tak naprawdę to już niewielka różnica (między tym a punktem 3) - skoro w 48K cała logika została zamknięta w nowocześniejszym chipie, i można tam jeszcze dorzucić procesor, bez przycinania funkcjonalności (złącze krawędziowe!), to co za różnica, czy ten Z80 będzie fizyczny, czy emulowany? To raczej właśnie podejście emocjonalne, że procesor, czyli serce komputera, powinien być fizyczny, prawdziwy, grzać się  i śmierdzieć . I trochę się z tym zgadzam, bo w sumie całe retro to bardziej serce niż rozum

Mi akurat procesor odtworzony w programowalnej logice nie przeszkadza. Problemy zaczynają się wtedy, jeśli odtwarzany układ miał jakieś istotne komponenty analogowe - tak jak SID z C64. Wtedy siłą rzeczy nie będziemy w stanie odtworzyć jego funkcjonalności za pomocą CPLD/FPGA.

...i opis zadania to jest właśnie algorytm!

Semantyka!
Gdyby chcieć stosować tak szerokie definicje to trzeba by uznać, że każdy układ logiczny (nawet ten złożony z bramek) realizuje jakiś algorytm. Mi chodziło o coś innego - w przypadku (software'owej) emulacji mamy sekwencyjny kod uruchamiany na procesorze, którego celem jest odtworzenie działania jakiegoś hardware'u. W przypadku FPGA mamy syntezowany kod, który odpowiada za odpowiednie skonfigurowanie połączeń między blokami. Jest on odpalany na etapie uruchamiania urządzenia, a potem FPGA działa już jak normalna sieć elementów logicznych. Dosłownie fizycznie istniejąca w krzemie, a nie naśladowana przez program odpalony na CPU.

Z programową - faktycznie nie.
Za to ze sprzętową - bardzo dużo. FPGA realizuje dokładnie to, co się potocznie nazywa hardware emulation. Bo nie ma tu żadnego fizycznego odwzorowania w krzemie, tylko jego udawanie poprzez sterowanie stanami logicznymi przez warstwę konfiguracyjną.

Ok, czyli mówimy teraz o dwóch różnych rzeczach. Ja cały czas mówię o emulacji programowej, bo w świecie miłośników komputerów retro jest to domyślne znaczenie. Można oczywiście też użyć szerszego znaczenia, za słownikiem języka polskiego PWN: "wierne naśladowanie działania systemu komputerowego lub jakiegoś jego elementu przez inny system komputerowy"

Nawet wtedy odtwarzanie takiej funkcjonalności FPGA nie będzie emulacją, bo nie jest "systemem komputerowym".
A jeśli rozszerzymy jeszcze trochę znaczenie, to za emulację trzeba będzie uznać odtworzenie ULA ze Spectrum w postaci bramek TTL.

Ale to znowu dyskusja o uczuciach. Dla jednych retro to komputer w oryginalnym kartonie w szafie za szkłem, a z kolei druga skrajność to emulator ZX na smartfonie. Plus oczywiście ileś gradacji uczuć pomiędzy skrajnościami.

I w sumie oryginalne podejścia są słuszne. Granie w gry sprzed trzydziestu lat na telefonie to ciągle granie w gry retro, chociaż nie na sprzęcie retro. To trochę tak jak dyskusja pomiędzy kolekcjonerem pierwszych wydań książek a kimś, komu zależy na tekście - choćby w formie ebooka.

Z trzeciej strony - moim peryferium numer 1 dla oryginalnych ZX jest divIDE. Scalaki z epoki (może poza flashem, ale można go zmienić na zwykły EPROM), no ale karta CF! Czyli już lata 90-te.

W Polsce ZX Spectrum był przez niektórych jeszcze mocno eksploatowany w pierwszej połowie lat dziewięćdziesiątych, a nawet później. Więc teoretycznie coś takiego mogłoby poznać, gdyby ktoś z użytkowników mógł sobie wówczas pozwolić na sprowadzenie karty CF.

hardware emulation is the process of imitating the behavior of one or more pieces of hardware (typically a system under design) with another piece of hardware, typically a special purpose emulation system. The emulation model is usually based on a hardware description language (e.g. Verilog) source code

Tylko to jest właśnie bardzo szerokie znaczenie terminu "emulacja" i gdyby się go trzymać, to trzeba będzie uznać, że emulacją jest odtworzenie funkcjonalności ULA za pomocą układów 74xx (czyli Harlequin też emuluje Spectrum!) albo zreprodukowanie jej metodą inżynierii wstecznej w innym kawałku krzemu. W potocznym i najczęściej stosowanym znaczeniu emulacja odnosi się do uruchamiania starego softu za pomocą programowego emulatora.

[tapy]

Tak, ale jednocześnie karta CF potrafi pracować także w trybie ośmiobitowym, dzięki czemu może pracować właściwie bezpośrednio na magistrali procesora. Czasami trzeba tylko dodać bufor zapewniający odpowiednie poziomy logiczne.

No to możesz się zdziwić, dlaczego spora część kart CF nie chce z Z80 działać - dokładnie problem opisałem tutaj i przy okazji powstał układ który nadal nie obsłuży wszystkich karty CF.  Jest to jakiś niewielki progres, który wszedł do oficjalnej linii produktów RC2014.

Co powiesz o filmie który zaprezentowałem post wcześniej? Jest to emulacja, czy hardwarowe odwzorowanie Z80? Ciekaw jestem odpowiedzi.

Zabawne jest to, że są też osoby które nie tolerują ESP w roli terminala, ale jako kartę WiFi już tak. 

[trojacek]

Tak, ale jednocześnie karta CF potrafi pracować także w trybie ośmiobitowym, dzięki czemu może pracować właściwie bezpośrednio na magistrali procesora. Czasami trzeba tylko dodać bufor zapewniający odpowiednie poziomy logiczne.

CF powstał na potrzeby przede wszystkim cyfrowej fotografii. A w tych urządzeniach, przynajmniej na początku, 8 bitów było spotykane często, a przy matrycach rzędu 1-2 megapiksele nie stanowiło to wąskiego gardła.
Trzeba by poszperać, czy aby w ATA nie powstał ośmiobitowy podstandard dla "wąskogardłowców" z lat 80 - np. XT.

Zobacz tutaj. Projekt zegara oparty na 8042. Działa to podobnie jak w przypadku 8051 - możesz mu kazać zignorować wewnętrzną pamięć i pobierać kod z zewnętrznej magistrali. Wtedy porty robią za szynę adresową.

Patrz, masz rację, profesor od systemów mikroporocesorowych wywaliłby mnie z kartkówki Przecież nawet 8051, czyli baza bazy (nie licząc 8048), ma ten tryb!
BTW, fajny projekt

Nic lepszego nie dostaniemy do czasu, kiedy ktoś wymyśli sposób na małoseryjną produkcję układów scalonych na podstawie kodu VHDL/Verilog. Dzisiaj to brzmi jak fantazja

Oceniam, że to kwestia jeszcze kilku lat. Czas pokaże

Problemy zaczynają się wtedy, jeśli odtwarzany układ miał jakieś istotne komponenty analogowe - tak jak SID z C64. Wtedy siłą rzeczy nie będziemy w stanie odtworzyć jego funkcjonalności za pomocą CPLD/FPGA.

Tzn. da się, ale z użyciem sztuczek i elementów zewnętrznych. Tak ma zrobione wyjście kolorów (R-Y, B-Y) implementacja ULA na CPLD/FPGA. A oryginalna ULA, jako bipolarna, dawała pewne pole do zabawy w analog.
Ale są już FPGA z AD/DA...

Semantyka!

Definicja to semantyka

w przypadku (software'owej) emulacji mamy sekwencyjny kod uruchamiany na procesorze, którego celem jest odtworzenie działania jakiegoś hardware'u.

Klasyka klasyki - software emulation, częściowy lub całościowy (bo mamy warstwę sprzętu w kawałkach lub w całości, jak również OS, oraz apliakcję).

W przypadku FPGA mamy syntezowany kod, który odpowiada za odpowiednie skonfigurowanie połączeń między blokami. Jest on odpalany na etapie uruchamiania urządzenia, a potem FPGA działa już jak normalna sieć elementów logicznych. Dosłownie fizycznie istniejąca w krzemie, a nie naśladowana przez program odpalony na CPU.

Czyli właśnie hardware emulation. Czyli, nawiasem mówiąc, istotny element prototypowania przy użyciu FPGA.
Problem leży częściowo w tym, że z racji potanienia technologii, prototypowanie to stało się rozwiązaniem docelowym. Bo w świecie hobby nie ma sensu zamawiać w fabryce docelowego układu ASIC. To dopiero byłby koszt

Ok, czyli mówimy teraz o dwóch różnych rzeczach. Ja cały czas mówię o emulacji programowej, bo w świecie miłośników komputerów retro jest to domyślne znaczenie.

Podobnie, jak adidasy to domyślne obuwie sportowe

Można oczywiście też użyć szerszego znaczenia, za słownikiem języka polskiego PWN: "wierne naśladowanie działania systemu komputerowego lub jakiegoś jego elementu przez inny system komputerowy"

Słownik PWN nie nadąża za technologią. Z definicji należy wykreślić słowo "komputerowy" i wtedy wszystko zaczyna się zgadzać.
Oto inny przykład z PWN:

procesor «najważniejszy element komputera, w którym odbywa się przetwarzanie informacji»

(https://sjp.pwn.pl/szukaj/procesor.html)

Tu PWN "zgubił" procesory tekstu, dźwięku, obrazu, ogólnie - DSP, a nawet procesor graficzny, który wcale nie musi być "najważniejszym elementem komputera", chyba, że kopiemy bitcoiny .

A jeśli rozszerzymy jeszcze trochę znaczenie, to za emulację trzeba będzie uznać odtworzenie ULA ze Spectrum w postaci bramek TTL.

No właśnie nie, bo układy TTL nie mają w sobie nic do zaprogramowania, więc intuicyjnie wykreślamy taką implementację jako emulację.
A ja wcale nie wykreślam, bo z jednej strony - konstrukcjach na układach TTL jest produktem końcowym, nie do przeprogramowania (no, lutownicą tylko...) itede, natomiast ja widzę implementację ULA na TTL jako wyodrębniony blok logiki, zastępujący konkretny układ systemowy, i jako taki jest jego emulatorem.
Podobnie, jak dla komputerów Macintosh i późniejszych z tej linii istniały karty z innymi procesorami, by np. zaemulować wcześniejszy model (Apple II) albo zupełnie inny komputer (PC). I tutaj to już w ogóle były hybrydy, bo oprócz emulacji sprzętowej (logiki charakterystycznej dla platformy) dochodziła często emulacja programowa (podsystem grafiki). No i obecność fizycznego procesora, oczywiście.

I w sumie oryginalne podejścia są słuszne. Granie w gry sprzed trzydziestu lat na telefonie to ciągle granie w gry retro, chociaż nie na sprzęcie retro. To trochę tak jak dyskusja pomiędzy kolekcjonerem pierwszych wydań książek a kimś, komu zależy na tekście - choćby w formie ebooka.

Dokładnie! Przy czym, jako użytkownik obu, przychylam się do rozwiązania bardziej praktycznego, a przy tym oszczędzającego las, wodę i energię. Rozumiem jednak, że dla kogoś innego będzie to podejście całkowicie ignoranckie i niedopuszczalne, i powinno być karane co najmniej wyłupieniem oczu

W Polsce ZX Spectrum był przez niektórych jeszcze mocno eksploatowany w pierwszej połowie lat dziewięćdziesiątych, a nawet później. Więc teoretycznie coś takiego mogłoby poznać, gdyby ktoś z użytkowników mógł sobie wówczas pozwolić na sprowadzenie karty CF.

Tak, ale od momentu wejścia na rynek (1995) karty CF upowszechniły się bardzo szybko, a z racji małych pojemności (pierwsze na rynku - firmy SunDisk, późniejszy SanDisk - miały pojemność od 2 MB do 15 MB) nie były jakoś horrendalnie drogie. No ale ja z tytułu mojej ówczesnej pracy miałem może łatwiejszy dostęp do nowych technologii.

Notabene pierwowzór divIDE powstał również w 1995 roku (jako Pera Putnik 16-bit IDE interface - https://piters.tripod.com/idehard.htm), ale jako interfejs dla dysku twardego. Dzisiejsze divIDE (57c) to już okolice roku 2000, kiedy karty CF można było kupić za normalne pieniądze. BTW, wykorzystywany jest 16-bitowy interfejs CF/IDE.

Eh, a miałem zamiar dziś wieczorem popykać sobie w RDR2...