Hej!

Ja wiem że już nie wierzycie iż kiedykolwiek skończę tego Slight SID-a... ale pokażę wam coś:

To fotka drugiego montowanego prototypu, pierwszy mam kompletny

Co działa na dziś:

Komunikacja Microchip<->ATARI
Przetwornica StepUP (możliwość ustawienia 9V lub 12V
Komunikacja SID-> MCU Microchip właściwie również zrobiona

pozostaje doszlifowanie softu dla microchipa. Miałem duże plany, np. wykorzystanie tego szybkiego microchipa jako koprocesora który by mógł różne rzeczy liczyć... ale przyznaję się bez bicia... straciłem chęci... ostatnio zajmuję się pierdołami zamiast kończyć ten projekt więc może go puszczę tak jak jest tylko z zaimplementowanym "ring buffer" buforującym dane nadsyłane przez ATARI i wysyłającym co trzeba do SID-a w odpowiednim dla niego czasie.

Ale niech ten gość może ciągnie swoją wersję SID-a na AT-Mega :) Pewnie uda mu się to zrobić wcześniej ode mnie :)

Ja bym w takim razie postulował następujące założenia:

2) asynchroniczna praca SID-a i ATARI, tzn SID chodzi na swoim zegarze, ATARI na swoim :) (to po to aby zachować wysokość granych dźwięków)
3) możliwość zmiany napięć zasilających +9V +12V, oraz przełączenia kondensatorów filtrów (to po to aby można było użyć zarówno starego 6581 jak i nowego 8580)
4) opcjonalna możliwość zamontowania dwóch SIDów :) (stereo power)

pozdrawiam
Seban

Hej!

Co do pchania MCU... kiedyś o tym pisałem. Głownie chodzi o problemy przy asynchronicznych zegarach SID/ATARI. Nie byłoby to jakimś strasznym problemem ale chciałem zachować możliwość prostego "STA SID_REGISTER", zmieniając tylko odwołania w PLAYER-ach z C64 z $D400 na $D500 bez żadnych poważnych modyfikacji player-ów w miejscach gdzie następowałby zapis do rej. SID-a.

Mam właściwie dwie wersje SlightSID-a:

1) Simple SlightSID - zbudowana przy pomocy paru zatrzasków HCT574 i paru bramek, waliło mi się to okrutnie ze względu na asynchroniczność (to moje założenie iż SID chodzi ze swoim ~0.98MHz a szyna ATARI ze swoim 1,773447MHz. Nie miałem możliwości sprzętowych w tamtych czasach aby to debugować porządnie więc odpuściłem na długi czas....

2) MCU SlightSID - na ideę tego wpadłem jak chciałem zrobić dopalacz Floating Pointów do ATARI. Wziąłem jakiegoś PIC-a serii 18 i podpoiłem przez PSP do szyny ATARI. Zadziałało bez zarzutu wiec postanowiłem dołożyć SID-a... ale potem zmienił mi się stan cywilny, pojawiła się żona... potem dzieciak... i czasu mało... Stryker mnie poganiał, interesował się, dopytywał a ja nie miałem czasu potem chęci aby dociągnąć to do końca.

Ale wracając do SIDów... do ATARI da się go podpiąć bardzo prosto praktycznie z wykorzystaniem naprawdę kilku scalaków, wtedy jest on taktowany synchronicznie do szyny Atari lecz z niższą częstotliwością (około 0,88MHz), co wymaga zmian w Playerach aby zmienić częstotliwości na właściwe. Takie rozwiązanie miał chyba GUMI/TIGHT ale nie do końca wiem bo tylko słyszałem to przez chwilę na jakiejś Ornecie chyba.

Na dzień dzisiejszy wiem jaki błąd robiłem podłączając asynchronicznie Simple SID-a i dało by się go podpiąć bez angażowania MCU. Ale skoro jest już prototyp z MCU to nie chciało mi się do idei SimpleSID wracać :)

pozdrawiam
Seban

MacGyver: RACJA :) $D280 to dobra IDEA :)

phnx: nie do końca rozumiem o co Ci chodzi co ma Antic i HALT wspólnego z podłączaniem MCU do szyny ATARI. Bo w przypadku SID-a to MCU czy logika czekają na zapis danych przez 6502 i w odpowiednim dla SID-a czasie ładują do niego dane zapisane przez ATARI, ATARI nie jest w żaden sposób wstrzymywane w tym momencie, dane są po prostu buforowane przez układ  Z tego co się domyślam ty chyba chcesz aby zewnętrzny MCU miał możliwość zatrzymania 6502 i grzebania po RAM-ie Atari.... tylko w jakim celu? Co chcesz osiągnąć?

pozdrawiam
Seban

XXL: wydaje mi się to możliwe i to do zrealizowania i to co najmniej na dwa sposoby :)

sposób nr 1) ładujesz w cart nowe CPU + RAM + FLASH dla niego np. do tego ładujesz mu kawałek (np. 8KB) statycznego RAM-u dual-port. Ten CPU w carcie działa sobie 6502 działa niezależnie, np. w obszarze $A000-$BFFF masz tzw. "shared memory" z tym dodatkowym CPU. Nowe CPU może liczyć co chce i przekazywać policzone dane w obszar swój "shared memory" który będzie widoczny przez 6502 w $A000-$BFFF. Ten sposób jest dość prosty do zrealizowania nawet, i jakiś czas już mi chodzi coś takiego po głowie :) Jedyna wada to to iż pamięci statyczne dual port jakie widziałem są drogie :(

sposób 2) można sie pokusić o halt-owanie 6502, tak jak robi to ANTIC (tylko trzeba by sprawdzać kiedy ANTIC haltuje 6502). I podpiąć inny CPU bezpośrednio do szyny danych ATARI (nota bene ten inny CPU również będzie musiał dopuszczać możliwość halt-owania go przez ANTIC). Poza tym chyba 6502 nie może być cały czas halt-owany (nie jest konstrukcją przewidzianą do pracy statycznej), ale tu nie mam zupełnie doświadczenia i trzeba by z Electron-em pogadać bo on już chyba z tym walczył przy okazji VBXE i rozszerzenia RAM-u które zrobił przy okazji VBXE :)

pozdrawiam
Seban

W przypadku MCU SlightSID tak... w przypadku SimpleSID nie przewidywałem takiej możliwości.

pozdrawiam
Seban

XXL: drugi CPU miałby własny niezależny RAM od ATARI (np. dodatkowe 512K) , a do tego 8K shared memory które byłoby widoczne jako okno w przestrzeni $A000-$BFFF przez 6502 w Atari. Zarówno 6502 jak i nowy CPU (dla przykładu np. EZ80 @ 50MHz lub 65816 @ 16MHz) mogły by pisać i czytać niezależnie do obszaru $A000-$BFFF.

Co do przypadku nr 2 to ja nie wiem co się dzieje z 6502 jakby go haltować tak aby nigdy nie miał dostępu do szyny :) Myślę iż Electron może wiedzieć bo zapewne spotkał się z takim problemem przy pracach nad VBXE i okolicach :) On by musiał podpowiedzieć czy takie rozwiązane jest realne :)

Hej!

Obawiam się iż ANTIC-a nie da się haltować i to z kilku powodów. Nie tylko DMA robi aby czytać dane potrzebne do tworzenia obrazu, odświeża on także pamięci DRAM. O ile mógłbyś go odpiąć od szyny danych i adresowej poprzez jakieś trój-stanowe bufory... (pomijam aspekt sieczki zamiast obrazu) to szlag by trafił zawartość pamięci DRAM. Z tego co pamiętam to ANTIC chyba 9 razy w ciągu jednej linii   ekranowej robi cykl odświeżania DRAM-ów... i tak cały czas linia w linę :)

Seban