@w1k: this topic is about the Commodore64 sound chip (SID8580) interfaced to 8-bit Atari. It is plugged into cartridge port. It works and can play most of the commodore SID tunes.

@grzeniu: zanim zaczniesz pisać jakie to gówno pomyśl trochę. Nie wiem czy znasz architekturę PIC-ów ale wydajnością to one nie grzeszą. Teoretycznie 1 instrukcja 1 cykl, ale CLKIN dzielimy na dzień dobry przez 4. Z 38MHz robi się 9,5MHz. Do kompletu każdy skok w programie zeruje namiastkę pipe-line którą posiadają Microchipy. Teraz wyobraź sobie iż mimo tego iż mamy jakieś tam ograniczenia wydajnościowe to właśnie to"gówno" potrafi przechwycić każdy zapis/odczyt z szyny atari. Do kompletu musi jeszcze znaleźć czas aby wykonać cykl/zapisu odczytu do SID-a. Teraz policz cykle i spróbuj oszacować ile cykli zostaje wolnych przy tych 9,5 MIPS-a. Ja wiem że to można zrobić prościej bez użycia MCU i tak było zrobione bardzo dawno temu...

możesz zrobić zawsze po swojemu :) do wyboru dowolna technologia :P

pozdrawiam
Seban

Ostatnio edytowany przez seban (2011-10-07 18:49:49)

Hey

Jestem zainteresowany jedna sztuka

nie bylo by tak zle jakby mozna bylo przeczytac rejestr $d51b chociazby dla programowego wykrycia z jaka koscia mamy do czynienia (stary/nowy sid) ale nie tylko...

no dobrze a obudowa?

A to nie można tego sprzętem odczytywać raz przy włączeniu zasilania i potem prezentować tę wartość w rejestrze interfejsu?

seban: no bo właściwie mcu tutaj jest bez sensu.

@grzeniu: MCU nie był taki bez sensu, bo miało to zaimplementowanie możenie/dzielenie stałoprzecinkowe, pakiet zmienno-przecinkowy zgodny z pakietem FP z ROM. Parę innych funkcjonalności (prawie emulowało 6510, CIA), emulowało super-chargera również. Grało właściwie SID-y samo. Szlag źródła pewnego dnia trafił, wszystko w było asm napisane. Później nie było czasu ani możliwości aby to odtworzyć. to co powstało teraz ma minimalną funkcjonalność.I tak jak napisał candle wersja finalna nie będzie miała już żadnego MCU. Jak pisałem wyżej pierwsza goła wersja była na TTL-kach miała minimalną funkcjonalność (write only) i działała równie dobrze.

Ostatnio edytowany przez seban (2011-10-07 20:59:04)

@xxl: można spróbować zaimplementować dodatkowe dwa rejestry jak w przypadku japońskich sound-chipów. Będziesz miał dwa dodatkowe rejestry INDEX, DATA. I to mogło by wyglądać tak:

lda #$1b
sta d5_INDEX
lda d5_DATA

no i git. kiedy wersja finalna (pi razy oko) ?

Jestem chętny - ale wszystko zależy od ceny - sidy ma własne :)

dla serii PIC16, PIC18 jest ciężko dobry kompilator napisać. Organizacja pamięci zarówno Flash jak i RAM woła o pomstę do nieba. W serii PIC16 podział na banki pamięci flash i RAM, a w PIC18 podział na banki pamięci RAM. Dobrze że dali 128 bajtów tzw. access ram, inaczej co druga instrukcja w kodzie programu byłaby przełączeniem banku :). Początki PICów chyba zaczynały się ponad 20 lat temu, od tego czasu wygląda to tak jak x86... łata na łacie. Być może PIC24 i dsPIC coś zmienia, ale nie miałem jakoś okazji aby się z tym zapoznać.

Ostatnio edytowany przez seban (2011-10-07 23:57:48)

@electron: czyli Microchip jak zwykle jeden krok w przód dwa kroki do tyłu ;) Ale słuchaj nie masz już jednego rejestru "W" :) teraz masz W0-W15 :P No i podobno nie ma już podziału na banki flash/sram ;)

Ostatnio edytowany przez seban (2011-10-08 19:12:05)