Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthorthewasp
   • CommentTime27 Jan 2024 19:01

    
   @gienekp: Częstotliwość synchronizacji układu na poziomie kilkuset MHz (zwłaszcza, że to wersja softcore'owa) nie będzie osiągalna. Nie tylko w przypadku mojej architektury - podobnych efektów należy się spodziewać przy zastosowaniu tożsamych rdzeni (można też spojrzeć na raporty westerndesigncenter, w obszarze IP core - licencje IP też są "towarem" ). Początkowo moim celem było stworzenie wersji 6502, którą da się podstawić do oryginalnej maszyny. Tak też się stało i procesor faktycznie był taktowany zegarem systemowym (phi2). Wersje przystosowane do współpracy z pamięciami synchronicznymi "latency one" powinny wyciągnąć więcej, ale wielkiego szału nie będzie. Jasne - sporo zależy od ośrodka implementacji, tyle że osiągi będą mniej-więcej zbliżone (mowa o układach FPGA o podobnych możliwościach). Prawdą jest, że zależność funkcyjna IP_count vs logical resources jest mniej - więcej liniowa (i tak - odpalałem wersje kilkurdzeniowe, w ciekawym układzie, ale to już temat na osobny wątek). Proponowany model akceleracji ataryny jest realny, należy jednak pamiętać o tym, że 6502 nie jest "spipeline-owanym riskiem", który gwarantuje throughput na poziomie mips/MHz. Lepiej wdrażać rdzenie specyficzne dla określonego zadania (przykładowo: Żaden procesor nie policzy tak sprawnie współrzędnych animacji "Bad Apple", jak zrobił to zaprojektowany do tego akcelerator i nie ma szans na równie sprawny blitter jak ten sprzętowy. Mówimy tutaj o częstotliwości taktowania = 25MHz. Ograniczała ją pamięć. Sam akcelerator "poszedłby" przy ok 300MHz). Hardware który zaprojektowałem da się przenieść na inną platformę, co potwierdza fakt, że układy obecnie stosowane (prod. Lattice) są całkowicie odmienne od tych, które stosowałem początkowo (Xilinx 6th/7th gen.), ale to wymaga pewnej pracy, ponieważ optymalizacja architektury bazuje na miejscowym wykorzystywaniu instancji elementów, właściwych dla wybranej architektury. To w żadnej mierze nie urasta do rangi problemu, nie mniej nie mam tutaj softu dla Altery/Intela.
2. • 2:
      
     CommentAuthorgienekp
   • CommentTime27 Jan 2024 23:01

    
   OK, kumam.
   Pytam bo pędziłem softproca NIOS II ponad 100MHz. 6502 riskiem nie jest ale też nie ma jakiejś specjalnie złożonej logiki więc poniżej 200MHz powinien iść.
3. • 3: CommentAuthorthewasp
   • CommentTime27 Jan 2024 23:01 zmieniony

    
   W wielopotokowych konstrukcjach RISC zmienia się model przetwarzania instrukcji, które same w sobie muszą spełniać warunek ortogonalności. Ścieżki asynchroniczne ulegają radykalnemu skróceniu, dzięki czemu maksymalna częstotliwość taktowania będzie wyższa. Dlatego właśnie pisałem o wariantach współpracujących z pamięciami "latency one" - tam potencjalnie będzie ciut lepiej (z tego co pamiętam, "Arlet" tak działa. Wiem jedynie że istnieje i w sensie zajmowanych zasobów logicznych wygląda podobnie, jak mój wariant). W przypadku 6502 da się sporo zrobić- to zresztą bardzo ciekawy pomysł na osobny projekt. Należy jednak pamiętać o tym, że odbędzie się to kosztem istotnego poszerzenia rozmiaru architektury
4. • 4:
      
     CommentAuthorgienekp
   • CommentTime28 Jan 2024 09:01

    
   Dokładnie. :)
   
   A że mamy coraz więcej LE w FPGA i coraz taniej i ten wirtualny 6502 miałby robić tylko kod a nie synchronizować się z peryferiami ATARI to w zasadzie finalnie byłby to sprzętowy emulator 6502. Zdaje się obecnie kod x86 w prockach też jest dziobany mikrokodem.
   
   Tak luźno fantazjując dopalamy 64 razy to tak wyjdzie 113MHz. Na tej częstotliwości lowcostowe fpegi wyrabiają w andach/orach i zatrzaskach. Chyba najbardziej złożony rozkaz to dodawanie. Nawet jak to będzie rozwinięte i zajmie więcej zasobów to pal licho (zresztą zaraz sprawdzę :) ).
   
   Gdyby udało się zrobić takiego cudaka co szybciej emuluje 6502 na real hardware niż procek na PC w emulatorze no to... wracamy do real ATARI na całego :)
5. • 5:
      
     CommentAuthorpirx
   • CommentTime28 Jan 2024 17:01

    
   pytanie lajkonika - a dałoby się zrobić 6502 takie, żeby działało z normalną częstotliwością, ale za to rozkazy wykonywałyby się w 1 cyklu? czy coś?
6. • 6: CommentAuthorthewasp
   • CommentTime28 Jan 2024 17:01 zmieniony

    
   Teoretycznie dałoby się to zrobić. Należy jednak pamiętać o tym, że nie ma fizycznej możliwości wykonania instrukcji w jednym cyklu zegarowym i nie chodzi mi o 6502, tylko o dowolną jednostkę. Wydajność na określonym poziomie (zbliżonym do 1MIPS/Mhz) uzyskuje się przez dokładanie równoległych potoków przetwarzających. W takiej sytuacji wiele zależy od zestawu instrukcji, stałości kodu, architektury (najczęściej Harvard - choć nie zawsze. Wypusty ARMa są "von Neumanowskie"). Ktoś od razu mógłby powiedzieć "NIE", ale podobny problem dotyczy również 8051, a jednak! Texas Instruments zaprezentował własną wersję rdzenia, gdzie postać kodu maszynowego utrzymuje kompatybilność, a wydajność jest utrzymana na zakładanym poziomie. Przedstawione pomysły są bardzo intrygujące. Oczywiście próżno zakładać, że po wyjęciu procesora z klasycznej atarynki i wstawieniu "upotokowionej" konstrukcji będziemy mieli szybszą maszynę - organizacja pamięci nie będzie już wystarczająca. W ramach nowej architektury, spełniającej wymogi sprzętowe - można walczyć.
7. • 7:
      
     CommentAuthorgienekp
   • CommentTime29 Jan 2024 08:01

    
   Zrobiłem symulacje w Quartusie i 120MHz jest do uzyskania. :)
   
   I teraz są dwie drogi. Jedna, łatwiejsza, wziąć gotowego darmowego softprocesora NIOS II i dodać mu "Custom Instruction". Wtedy te ATARowskie będą dodatkowymi do normalnego RISCa 32-bity. I one będą wszystkie dwucyklowe.
   
   Lub zrobić w od nowa 6502 ale taki dopalony zgodny co do wykonania algorytmu. Ta droga jest ciekawsza. Bo w tej opcji procek jest tym drugim. A więc nie musi spełniać rygorów obsługi ATARI. Ma tylko kod 6502 wykonać zgodnie z algorytmem. Czyli jak ktoś napisał funkcję rysowania koła dla 6502 to dokładnie tak samo się to wykona tylko 64 razy szybciej. W sumie magistrala od dopalonego 6502 może być 32 bitowa więc w pierwszym cyklu pobierze 4 bajty. A to oznacza, że większość spraw załatwi w dwóch cyklach.
   
   Najfajniejsze, jest to, że taka dopałka wisząca na carcie będzie śmigać ze zwykłego XEX/COM.
8. • 8: CommentAuthorthewasp
   • CommentTime29 Jan 2024 11:01

    
   Niestety - problem jest znacznie bardziej złożony, niż mogłoby się wydawać. To jedna z przyczyn, dla których nie przebieramy w dobrych, powszechnie dostępnych, softcore-owych reimplementacjach 6502.
9. • 9: CommentAuthorthewasp
   • CommentTime29 Jan 2024 12:01

    
   @gienekp: Poruszyłeś ciekawy temat: Zastanówmy się nad charakterem wyzwania przy podobnym zadaniu - jaka jest wydajność procesora emulowanego na np. RBPi? (pomijam tutaj aspekty czasu rzeczywistego). To raczej łatwo zbadać, odpalając emulator.
10. • 10:
       
      CommentAuthorjhusak
    • CommentTime29 Jan 2024 15:01

     
    @thewasp - pirxowi chodziło o to, żeby taki procek wykonywał 1 instrukcję w jednym cyklu ATARI. Jednak, aby to zrobić, trzeba by duplikować dane w wewnętrznej pamięci, bo taki lda(23)y, to: weź lda, weź 23, weź 24, pobierz daną z adresu 23/24 z offsetem y. To jeśli nie mamy keszu to nijak się nie da w jednym cyklu.
11. • 11: CommentAuthortebe
    • CommentTime29 Jan 2024 15:01

     
    Pirx-owi od dobrobytu w głowie się przewróciło
12. • 12:
       
      CommentAuthorjhusak
    • CommentTime29 Jan 2024 16:01 zmieniony

     
    To i mi też, bo też chciałem taki gadżet. Procek, co rozkaz działa w jednym cyklu, jeśli instrukcja jest skeszowana, to nawet w jednym cyklu zrobić kilka operacji. Np. asl asl asl asl. Jedyne, co trzeba zrobić na prawdziwej pamięci zawsze, to zapis oraz dodatkowo odczyt z obszaru $D000-$D7FF.
13. • 13: CommentAuthorthewasp
    • CommentTime29 Jan 2024 16:01

     
    1 cykl zajmie dekodowanie instrukcji, bo musi. Nawet jeśi założymy, że pobranie wszelkich niezbędnych danych odbędzie się przez odpowiednie poszerzenie magistrlai danych, to złożoność części asynchronicznej będzie na tyle duża, że przedsięwzięcie bardzo szybko straci sens. Bez sporej przebudowy architektury nie da się osiągnąć zamierzonego efektu.
14. • 14: CommentAuthortebe
    • CommentTime29 Jan 2024 17:01

     
    no ale miliony użytkowników i setki milionów nowych aplikacji są nie do przecenienia ;)
15. • 15:
       
      CommentAuthorjhusak
    • CommentTime29 Jan 2024 17:01

     
    Wiesz, tebe, nie zawsze musi być milion użytkowników, żeby coś miało sens. Często wystarczy jeden użytkownik, żeby czemuś ten sens nadać. Jestem pewien, że takich zapaleńców, co nic nie mówią tylko robią dla siebie jest dużo więcej, niż myślisz.
16. • 16: CommentAuthortebe
    • CommentTime29 Jan 2024 17:01

     
    tutaj masz swój CPU
    
    ->link<-
17. • 17: CommentAuthorthewasp
    • CommentTime29 Jan 2024 18:01 zmieniony

     
    @tebe: Twory o wirtualnym charakterze (amigowy "brainf*ck", wirtualna maszyna interpretująca bytecode javy, czy powyższy, excellowy) to osobna historia. Spełniają założenia Alana Turinga (w sensie maszyny "zupełnej") i nie mam najmniejszych wątpliwosci, ze @jhusak w ogóle nie musi zapoznawać z materiałem, żeby stworzyć znacznie lepszy - nawet na atarynkę. Osiągnięcie wymiernych efektów
    w sferze sprzętowej jest realne, a dyskusja - potrzebna.
18. • 18: CommentAuthorthewasp
    • CommentTime29 Jan 2024 20:01 zmieniony

     
    ... a wracając do dyskusji: W dzisiejszych czasach pamięć "kieszeniowa" jest elementem niezbędnym. Zawsze chodzi o "przyspieszenie", tyle że głównym problemem jest "burstowy" charakter dostępu do pamięci dynamicznych. Jeśli system z góry zakłada ich wykorzystanie, to z zwykle nie ma problemu z utrzymaniem spójności fizycznie rozdzielonych obszarów (cache coherency). I taki problem nie występuje platformie związanej z tym wątkiem. W realnym sprzęcie (Atari)... cóż - byłoby dość kiepsko. Tym lepszy system cache'owania, im bardziej "randomowy" dostęp zagwarantuje, na tle "nierandomowej" natury ośrodka składowania danych, połączonej z wielodostępem. Dobry projekt systemu tego typu może być (i zwykle jest) bardziej złożony, aniżeli elementy, które żądają dostępu do pamięci. To ciekawe zagadnienia, którymi zajmuję się w osobnym projekcie. Jest bardzo prawdopodobne, że będą realizowane i tutaj - wszystko zależy od tego, czy będzie miało to sens. Dlatego cieszę się z zainteresowania tematem i z reakcji. No ale po kolei. Z mojej strony czas na następny krok, którego efekty postaram się opisać już wkrótce.
19. • 19: CommentAuthor8-Bitz
    • CommentTime30 Jan 2024 08:01

     
    oglądałem na YT - więcej takich filmów i więcej takich projektów. Serce napawa się optymizmem jak to się ogląda! Widziałem też wpis, w tym wątku, z płytą ITX - nie głupi pomysł żeby zrobić to tego mini FPGA jakiejś płyty matki, co wejdzie ten FPGA i będzie miał wyjścia zgodne z jakimś standardem typu ITX (albo RPI ;))
20. • 20:
       
      CommentAuthorgienekp
    • CommentTime30 Jan 2024 15:01

     
    Słynne POKE 559,0 wyłączy mi wszystkich złodziei cyklów? Czy coś jeszcze może opóźnić CPU?
    
    No bo zdaje się, że emulator ATARI800 można puścić na maks prędkość emulacji. To będzie można sprawdzić ile LDA-STA może machnąć emulator na rPI a ile np. na Applowym M1.
    
    Bo faktycznie dopałka CPU może być softowa. A my mamy już carty na rPI, tylko nikt nie pomyślał, że można nimi kod 6502 machnąć :)
21. • 21:
       
      CommentAuthorpancio
    • CommentTime30 Jan 2024 16:01

     
    Muszę przyznać, że wasze wywody wykraczają poza moje rozumowanie bo choć wiem o czym mówicie to ni w ząb nie wiem jak miałbym się za to zabrać :-) Kibicuję i mam nadzieję skorzystać w przyszłości z owoców waszej pracy :-)
22. • 22: CommentAuthorthewasp
    • CommentTime30 Jan 2024 16:01

     
    @gienekp: W opisywanym sprzęcie, obecnie ANTIC nie przeszkadza "procesoru", czyli poke 559,0 nie wpłynie na ciągłość jego pracy. Dzieje się tak, ponieważ dyspozytor pamięci pracuje z częstotliwością ustaloną na prawidłową pracę układu graficznego w najgorszym możliwym przypadku (czyli gdy wszystkie obsługiwane przez niego elementy żądają dostępu do pamięci), natomiast CPU jest taktowany sygnałem z drugiej "domeny", o częstotliwości gwarantującej pracę zbliżoną do oryginału (pomijając, że ANTIC go nie haltuje). Gdy procesor będzie pracował z częstotliwością synchronizacji dyspozytora, to tak - wtedy poke 559,0 będzie miało znaczenie. To zostawiam na później. Sama konstrukcja "MMU" pozwala już wdrożyć cache (niskiego poziomu - na blockramach, czyli bez szeleństw, ale zawsze lepiej niż w ogóle)
23. • 23:
       
      CommentAuthorgienekp
    • CommentTime30 Jan 2024 22:01

     
    Ok, wychodzi mi tak. Że w zasadzie dopalacz można zacząć od zrobienia emulatora kodu 6502. Czysty soft w C i zobaczyć jak to może wymiatać. Nawet cyklowanie można olać, byleby kod co do wyniku się zgadzał. Wszystkie chwyty dozwolone.
    
    Czyli taki przykład:
    

    ORG $A000
    LDA A
    AND B
    STA Y
    RTS
    
    ORG $B000
    Y dta $00
    A dta $05
    B dta $07
    

    
    No to może skoczyć ATARowski procek na $A000 i wykonać kod i wynik się pojawi na $B000. Lub każemy dopałce wykonać kod od $A000 a że ten obszar widzi system ATARI przez okienko cartridgea to i wynik zobaczy.
    
    No nic... trzeba włączyć tryb "old school" i napisać funkcję w C do emulacji kodu. Jak będzie wydajna to można przejść na Verilog/VHDL :)
24. • 24:
       
      CommentAuthorjhusak
    • CommentTime30 Jan 2024 23:01 zmieniony

     
    Mnóstwo różnych podejść jest w internetach.
    Jest w Atari800, jest sim6502 w cc65 to na razie tyle, co pamiętam.
    Jest oczywiście też otwarty w fpga, brać i testować.
    
    Pisanie tego samemu jest tyle upierdliwe, co czasochłonne. Można się spełnić i próbować napisać najszybszą implementację, która by zadziałała np. na mikrokontrolerach tak szybko, że można by podmienić procka. Albo wersję minimalistyczną.
    
    Ale to oczywiście moje zdanie :)
25. • 25: CommentAuthorthewasp
    • CommentTime31 Jan 2024 00:01

     
    Można powiedzieć, że software'owe implementacje na szybkich komputerach wyznaczają określoną granicę, która jest ciekawa - bo pozwoli odpowiedzieć na pytanie, na ile realny jest proponowany powrót "na całego" do 6502.
    
    Pecetowy atari800win pokazuje mi od 5000% do 18000% - to już jakaś informacja.
    
    50krotne przyspieszenie jest realne, a przy konfiguracji wielordzeniowej i możliwie zwartej architekturze - zabawa mogłaby być ciekawa.
26. • 26:
       
      CommentAuthorjhusak
    • CommentTime31 Jan 2024 13:01 zmieniony

     
    Problem Jasia na turbo 3 minuty idzie w sekundę ma Macbooku M1, atari800, ze wszystkim, obrazem, dźwiękiem etc. czyli 180 razy szybciej. Sam procesor 6502 podejrzewam wyciągnie pod gigaherc. Przy dobrym zakodowaniu jedna instrukcja 6502 może zająć kilkanaście operacji/cykli, myślę, że na takiej Atmedze 20 Mhz spokojnie dałoby się 1:1 procek zaimplementować, tzn 1-2Mhz.
    
    Ci, co zrobili to w 2003, twierdzili, że działa wolniej. ->link<-
27. • 27: CommentAuthoradi
    • CommentTime31 Jan 2024 14:01 zmieniony

     
    Fajny temat i fajna dyskusja.
    Też od dłuższego czasu kręciłem się wokół tematów emulacji i budowy małych procesorów.
    Nawet ostatnio mnie naszło i zmusiłem swój komputerek z drutów i TTL-i (bez procesora) do policzenia liczby PI, np. 256 znaków po przecinku.
    Jest słabszy od 6502 choć wewnętrznie podobny i przeportowałem kod właśnie z 6502.
    Generalnie świetna zabawa, z tym że nie ma co szukać sensu, bo dochodzi się do wniosku, że PC-ty to najlepsze komputery domowe na świecie :).
28. • 28:
       
      CommentAuthorgienekp
    • CommentTime31 Jan 2024 16:01

     
    No koduje sobie powoli, wskaźniki itd. Zapiernicza to niesamowicie. :)
    
    Jak z tego coś wyjdzie to na pierwszy ogień pójdzie podmianka PLOT i DRAWTO z ATARI BASIC. Bo zdaje się, że bank carta jest wpinany identycznie jak BASIC. To można lekko spreparować funkcje, żeby zamiast skakać do OS to spuści ze smyczy dopalonego 6502.
    
    ATARI BASIC 100MHz. Ciekawe by to było :)
    
    
    @thewasp
    Myślałeś, żeby "krzywymi" dopalić zwykłe rysowanie linii?
29. • 29: CommentAuthorthewasp
    • CommentTime31 Jan 2024 19:01 zmieniony

     
    Porównywanie prostego programu symulującego pracę 6502 i "legitnego" układu cyfrowego nie może iść za daleko, ze względu na zjawiska czasu rzeczywistego, które w wyższej rozdzialczości czasowej będą poza kontrolą software'owej implementacji (wystarczy rzucić okiem na waveformy, związane z cyklem dostępu do pamięci). W przypadku atarynki, "Kwantem czasowym", wystarczającym do względnie wiernej (software'owej) symulacji behawioralnej (tutaj nie chodzi mi o symulację układów cyfrowych ;) - dokładniej to o to, że program jest zgodny z tworem fizycznym na poziomie efektów jego pracy) oryginału będzie cykl koloru, na poziomie softu określany mniej lub bardziej umownie, tzn. nie w synchronizacji RT (ciężko wyobrazić sobie "eventy" o częstotliwości kilku MHz, synchronizujące aplikację, pracującą zresztą pod kontrolą systemu operacyjnego). Stąd typowy emulator nie ma jak radzić sobie precyzyjnie z wszelakimi problemami czasowymi sporego zbioru sprzętowego - no chyba że czegoś nie wiem.
    
    Jeśli cały program pracuje jednowątkowo, to podział mocy obliczeniowej procesora będzie nieco trudniejszy do przewidzenia, aniżeli w przypadku, w którym podzielimy częstotliwość taktowania procesora przez średnią liczbę cykli na rozkaz. Stąd maksymalna prędkość na takim RBpi, wyciskana w opisywanym trybie jest interesująca.
    
    Oczywiście nikt nie ma zamiaru tworzyć sprzętu, który miałby stawać w szranki ze współczesnymi "potworami" przetwarzającymi :). One owszem - są rewelacyjne, ale do zegarka na rękę nie wlezą ;)
30. • 30: CommentAuthorthewasp
    • CommentTime31 Jan 2024 19:01 zmieniony

     
    @gienekp: Chodzi Ci o dopalenie grafy w oryginalnym sofcie ATARI? Układ kreślenia krzywych obsługuje kilkanaście rejestrów (definiujących m.in. organizację danch VRAM, rozmiar obrazu). Kluczową rolę odgrywają te, którym przekazuje się współrzędne ekranowe, oraz wektorów charakterystycznych. Sygnalizacja końca rysowania odbywa się klasycznie. Przez polling rejestru statusu, lub IRQ. Pewnie, że by się nadało - tylko trzeba by było zmodernizować soft. @jhusak ogarnął last ninja, podobna akcja byłaby dla niego prosta.
    
    I znowu świetny pomysł :) - funkcja kreślenia wówczas w zasadzie zniknie... To samo można zrobić z pakietem matematycznym...
31. • 31:
       
      CommentAuthorDracon
    • CommentTime1 Feb 2024 09:02 zmieniony

     
    Nie znam się, to się wypowiem. ;)
    
    - Czy to miniaturowe Atari będzie mogło uruchamiać wszystkie lub większość programów z biblioteki oprogramowania jaka istnieje dla modeli XL/XE ? Jeśli nie, to jakie są ograniczenia?
    
    - Czy będzie to działać z szybkością 1:1 oryginału a tylko w razie czego można sobie włączyć na życzenie "tryb turbo" ?
    Dzięki za uwagę.
32. • 32: CommentAuthorthewasp
    • CommentTime1 Feb 2024 11:02

     
    @Dracon: Pytania dotyczą zasadniczych założeń (zgodność - tak, turbo - tak) .
    
    W chwili obecnej główne różnice wynikają ze specyfiki wybranych standardów video (VGA / DVI-HDMI), gdzie częstotliwości synchronizacji są inne. VBLK na poziomie 60Hz zbliża urządzenie do wersji NTSC. Rezygnacja z "modern video" na rzecz CVBS/SCART RGB zredukuje ten problem.
    
    Układy zostały zaprojektowane niezależnie, tj. w oderwaniu od dokumentów technicznych (wyjątkiem jest tutaj POKEY, którego wewnętrzne schematy były obiektem analizy w trakcie opracowywania architektury), dlatego racjonalne różnice o których nie wiem w chwili obecnej, będą niwelowane - właśnie na drodze uruchamiania oryginalnego oprogramowania.
    
    Pracujemy obecnie nad wersją ostateczną hardware'u (PCB), która wszystkich powinna pozytywnie zaskoczyć.
33. • 33:
       
      CommentAuthorgienekp
    • CommentTime1 Feb 2024 16:02

     
    Emulator Altirra dość dobrze odwzorowuje sprzęt, ale widać że potrzebuje na to dość sporo zasobów PCta.
    
    Z drugiej strony testuje sobie robiony emulator, z tym że u mnie "kwant" to jest jedna instrukcja, bez względu na to ile cykli ma. Pi razy drzwi na intelu 1.2GHz w ciągu sekundy robię 90mln operacji "JMP addr". Jak zrobię wszystkie kody to puszę OSowe DRAWTO w takiej emulacji na rPI i będzie można porównać ile linii (0,0)->(319,191) można na sekundę walnąć przy takim podejściu.
    
    Będzie można porównać jak się to ma do emulacji sprzętowej, zasobów mocy, wielkości PCB itp.
    Czysta ciekawość, czy 6502 lepiej klepać softem czy jednak hardwarem. :)
34. • 34: CommentAuthortebe
    • CommentTime2 Feb 2024 01:02

     
    tutaj przykład jak to rozwiązali w neo6502, korzystanie z rPI poprzez messages
    
    ->link<-
35. • 35: CommentAuthorthewasp
    • CommentTime4 Feb 2024 23:02

     
    Wykonanie obwodów drukowanych we własnym zakresie bywa przydatne... (0402, min. width: 6 mils, hole size:0.25mm)

    • mobile_photo_1.png
      
      
      
      
36. • 36: CommentAuthortriplex aka blasph
    • CommentTime4 Feb 2024 23:02

     
    ładne :)
37. • 37:
       
      CommentAuthorjhusak
    • CommentTime4 Feb 2024 23:02 zmieniony

     
    Jmp addr jest trochę niemiarodajne, bo nie uaktualnia flagów procesora. Spróbuj ADD xxxx. Ale i tak widać, że procek/zegar można podzielić przez 10 lub 20 i jest to realna prędkość emu. W nowszych prockach przez mniej, ale nie wiem, /7 czy przez 5?
    
    A takie pcb jest łatwo zrobić, jak się ma dobrą drukarkę laserową :) Oczywiście 0402 to już "piasek", i miałbym trudności ze złapaniem pęsetą bez lupy, ale chwilowe :) Standardowo robię 0603 i jest git.
38. • 38: CommentAuthorthewasp
    • CommentTime4 Feb 2024 23:02 zmieniony

     
    drukarka laserowa + fotochemia to jedno. Precyzyjne wiercenie - to drugie (a brak metalizacji - trzecie). Ale i tak cały czas wierzę w tę metodę (obwód dwustronny). Przy moim wieku/wzroku muszę polegać na automatyzacji. Ha! Wiertarką numeryczną steruje... "atarino" z customowym procesorem trajektorii. Film z wiercenia na pewno dostarczyłby rozrywki...
39. • 39: CommentAuthorthewasp
    • CommentTime5 Feb 2024 00:02

     
    (wiercenie wykonywane jest przed naświetlaniem)
40. • 40: CommentAuthorthewasp
    • CommentTime20 Feb 2024 00:02

     
    Czołem!
    
    Zakończyłem etap uruchamiania zoptymalizowanego streamera TMDS (DVI/HDMI), związanego z "micro MoBo" - obwodu bazowego, zdecydowanie lepiej dopasowanego do specyfiki aplikacji. Dokładne informacje już wkrótce, a obecnie (ponieważ efekty cieszą) - krótka wzmianka na "dobranoc".
41. • 41:
       
      CommentAuthortOri
    • CommentTime20 Feb 2024 11:02 zmieniony

     
    Dobre! Kibicuję!!
    PCB najwygodniej jest zamawiać w Chinach. Tanio i dobrze :)
42. • 42: CommentAuthorthewasp
    • CommentTime21 Feb 2024 00:02

     
    W przypadku większych zleceń, wielowarstwowych obwodów o złożonej naturze, względnie prostych, ale o "finalnym" layoucie - jasne, rozwiązania inne niż zlecenie produkcji mają bezsensowny/nierealny charakter.
    
    Czasami sprawa wygląda inaczej - głównie w przypadku testów jednostkowych i wczesnych rewizji, podatnych na błędy. Wtedy cała ta "cepelia" potrafi być bardzo przydatna.
    
    Przytoczony sposób wykonania prototypu mógł sprawiać dziwne wrażenie, jednak rychło "zapunktował", gdy okazało się że topologia wyprowadzeń jednego elementu nie była prawidłowa. Następnego dnia miałem już kolejny egzemplarz...
43. • 43:
       
      CommentAuthorjhusak
    • CommentTime21 Feb 2024 21:02 zmieniony

     
    Kwestia, jak cenisz swój czas i ile masz projektów na stole :) No i czy to lubisz (to trawienie), bo to może być satysfakcjonujące :)
44. • 44: CommentAuthorTMJ
    • CommentTime22 Feb 2024 03:02

     
    Szalenie ciekawe. Retro FPGA wchodzi pod strzechy. Niesamowite.
    Może ktoś zainspiruje się i zacznie podobne projekty ucząc się jak to działa, wykorzystując jako środowisko symulacyjne np. Excela …. tak na początek:
    
    

    
    
    Pozdrawiam i życzę sukcesu :)
45. • 45: CommentAuthorthewasp
    • CommentTime2 Mar 2024 00:03 zmieniony

     
    Fotografia wersji pośredniej/rozwojowej. Ponieważ walidacja mechanizmów kodowania/strumieniowania wideo jest już faktem (i wobec obecności interfejsów, których po prostu mi brakowało), mogę wrócić na tor związany ze specyfiką ATARI. Kontroler TMDS został zoptymalizowany, ale nie uproszczony. Zaletą jest tutaj możliwość wprowadzania pełnych słów kodowych (architekturę układu binarnego balansowania strumienia można znacząco zredukować, przez ograniczenie przestrzeni barw do 4096), co gwarantuje nie tylko możliwość odwołania się do palety true color - nie wyklucza również kodowania dźwięku w przyszłości. W zakresie pełnej kompatybilności strumieniowej ze standardem HDMI należy jednak zachować ostrożność.

    • pico_explained.jpg
      
      
      
      
46. • 46: CommentAuthorthewasp
    • CommentTime2 Mar 2024 00:03 zmieniony

     
    Ponieważ trudno oszacować wielkość urządzenia na podstawie poprzedniego załącznika, dokładam kolejne zdjęcie

    • pico_1.jpg
      
      
      
      
47. • 47: CommentAuthorthewasp
    • CommentTime7 Mar 2024 21:03

     
    Czas na trochę bardziej konkretny materiał. W załączeniu zdjęcia z etapu testów komunikacji SIO (POKEY + PIA/CB2 - command). Obraz: HDMI @ 640x480 (VGA, industry standard).

    • pico_colossus.jpg
      
      
      
      
48. • 48: CommentAuthorthewasp
    • CommentTime7 Mar 2024 22:03 zmieniony

     
    Battle ships. Rozszerzona architektura ANTICa (w obszarze interpretacji generatora znaków) daje o sobie znać. Kontrolowana nieprawidłowość. Wkrótce kolejna odsłona - czas ocenić jakość przebiegów akustycznych. Choć problem transmisji szeregowej wydaje się dość trywialny, należy pamiętać o konieczności utrzymania kompatybilności projektowanych układów z oryginalnymi elementami - oprogramowanie nie zna słowa "przepraszam" ;)

    • pico_ships.jpg
      
      
      
      
49. • 49:
       
      CommentAuthorpirx
    • CommentTime10 Mar 2024 17:03

     
    najs
50. • 50:
       
      CommentAuthorpancio
    • CommentTime12 Mar 2024 08:03

     
    @Thewasp, tu nie ma nic trywialnego... to jest po prostu przepaść technologiczna. Ja co prawda siedzę twardo w technologii i elektronice ale to co pokazujesz przekracza moje zrozumienie tematu. Brawo!