any update on the card?
Interesse an C16 SID-Karte
-
cbmhardware -
4. September 2005 um 14:53 -
Erledigt
Es gibt 137 Antworten in diesem Thema, welches 34.591 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Zitat
Problem ist wohl das der C16 +4 zu schnell für den SwinSID ist :baby:
[...]
so ein mist... wenn hier oder sonstwo noch jemand ein paar ideen hat dann mal her damit...sonst hat sich das fast schon erledigt...

Wenn der die Daten verpasst, hast Du sicher schlechte Karten. Ich werde es mal auf dem klassischen Weg nachbauen. Für die Taktung werde ich irgend etwas passendes nehmen, damit der SID-Speed dem C64 entspricht. Mal ein paar Counter vergewaltigen und mit dem Oszi nachmessen.
Die Dekodierung werde ich imo mit einem Bauteil + einer Leitung vom PLA hinbekommen.
Diesen TL497 in Solders Schaltung halte ich auch für etwas übertrieben. Da reicht doch eigentlich ein Regler + Kleinkram und evtl. noch eine ZDiode. Dieser Analog-Port auf $fd80 wurde imo auch noch nie genutzt - wozu einbauen ?
Gesamt habe ich für meinen aufgebohrten C16 folgendes geplant :
Code
Alles anzeigen--- %1111110100010000 $fd10 - ($fd1f)== Userport %1111110101000000 $fd40 PLA(F5 :PIN12)+(A6=1)+(A5=0)+(A4=0) == SID %1111110101011111 $fd5f %1111110101100000 $fd60 PLA(F5 :PIN12)+(A6=1)+(A5=1)+(A4=0) == Memory-Expansion (512kB- ?) %1111110101101111 $fd6f %1111110101110000 $fd70 : reserved %1111110110000000 %fd80 PLA(F5 :PIN12)+(A7=1)+(A6=0)+(A5=0) == Amiga Clockport ---Der Userport wird ein VIA6522 und nicht kompatibel zum sowieso ungenutzten (auch kaum nutzbaren) Plus/4-Userport. Da kann man dann evtl. auch mal einen MAX dranhängen, wenn man heute noch ein serielles Interface nutzen möchte.
Mal sehen was daraus wird ... ein Adapter CPU+SID ist schon mal fertig.
Michael
-
Die Dekodierung von gestern vergessen wir besser ganz schnell wieder. Das mit der Leitung vom PLA klappte nicht. Ist aber nicht so schlimm. Nun werden die Adressen mit zwei TTLs verknotet. $fd10: Userport ist nach $fd50 gewandert. Der C16 verwendet $fd10 für den Cassetten-Port.
Der SID braucht so noch ein weiteres Bauteil, damit auch genügend Adressraum da ist. Die beiden CS für den SID werde ich mit einem 7408 verbinden. Ein Königreich für ein GAL-Programmiergerät.
Code$fd00 : Userport (PLA) ; Plus/4: ACIA, C16: unused ------- $fd40 : SID $fd50 : SID $fd60 : Memory-Expansion $fd70 : reserved $fd80 : Amiga Clock-Port $fdc0 : reservedEin neuer 6582 HMOS-SID ist schon auf der Platine zu sehen. Ist im Moment aber noch nicht bedrahtet. Gibt es eigentlich irgendwelche Programme für den C16, die den SID an $fd40 nutzen ?
Michael
-
Ein Königreich für ein GAL-Programmiergerät.

Nimm doch irgendein via JTAG programmierbares CPLD, zB aus der XC95xx-Reihe von Xilinx. Bei denen reicht ein PC-Parallelport und ein 74irgendwas als Puffer zur Programmierung und die kleineren Modelle gibts im PLCC-Gehäuse das mit passendem Sockel auch auf Lochraster verbaubar ist. -
Ich habe leider keine Ahnung von VHDL und diesen neuen Arrays. Aber das müsste man sich wirklich mal aneignen, ist schon richtig.
Mein SID funktioniert schon mal grundlegend. Der 7408 ist nun drauf und alles angeklemmt. Ich habe für den ersten Test diese PHI2-Clock (?) des C16 verwendet. Muss noch etwas passenderes finden. Auf dem Oszi sieht es noch etwas "matschig" aus.
Die Bild-Qualität kommt etwas vom laufenden Bild auf meinem antiquierten Oszi.Im Kopfhörer konnte man jedenfalls schon mal alles hören.

Hat jemand einen SID-Tune für den C16 da ?
Michael
-
Ich habe leider keine Ahnung von VHDL und diesen neuen Arrays.
Bei Xilinx kann man für CPLDs auch ABEL verwenden, das ist evtl. von GALs schon bekannt. -
Ich habe mir das von Altera mal angesehen. Läuft auf meinem alten Rechner nicht. Damit brauche ich im Moment noch nicht anfangen. Müsste mir erstmal einen neuen PC, Betriebssystem, etc. kaufen.
Naja, da sind die zwei TTLs für 30 Cent im Moment noch die einfacher nachzubildende und billigere Lösung.Etwas anderes : Ich möchte den Speicher des C16 aufrüsten. Die Anleitung mit Anlegen von A14,A15 an die Multiplexer kenne ich. Ich möchte aber lieber Multiplexer und RAM entfernen. Dafür wird dann ein SRAM eingesetzt. Wenn man dieses vorhandene MUX-Signal invertiert, sollte sich daraus doch ein /CE für das neue RAM generieren lassen ?
Bitte melde dich an, um diesen Link zu sehen.
Btw: das 8bit-baby war scheinbar auch eine Totgeburt. Die Homepage ist verschwunden. Da hätte man es mal mit einem dieser ATMELS versuchen können. Obwohl das auch sicher wieder an meinem alten PC scheitern würde.
Michael
-
Ich möchte das Thema "SwinSID im Plus/4" nochmal aufgreifen:
Problem ist wohl das der C16 +4 zu schnell für den SwinSID ist :baby:
Da der C16 +4 meist mir 1,76 MHz läuft und der SwinSID (AVR) so schnell die Daten nicht übernehmen kann...
Da der AVR im neuen SwinSID88 ja deutlich höher getaktet wird als der ursprüngliche SwinSID, frage ich mich, ob dieser nicht auch im Plus/4 laufen würde.
Besteht da eine theoretische Chance?CU
Kratznagel -
Der originale SID-Mod beinhaltet eine Takthalbierung, der SID läuft also auf 880kHz und damit langsamer getaktet als im C64, wodurch er auch etwas anders klingt.
-
Interessant. Dann liegt es also nicht daran, dass der Plus/4 "zu schnell" ist, sondern dass das Poll-Timing des SwinSID (der ja seinen eigenen Takt hat) einfach nicht passt. Die SwinSID-Hardware wäre also vielleicht schon für einen Einsatz im Plus/4 geeignet, aber dann wohl nur mit einer modifizierten Firmware, die auf die 880 kHz angepasst ist? Hmmm...
CU
Kratznagel -
nur wenn vorher der MUX (nicht Systemtakt wie ich vorher schrieb) halbiert wird. Ferner muss die Adresse für den SID aufbereitet werden mittels TTL oder GAL ( $fd40 )
Hier wirdst Du fündig: Bitte melde dich an, um diesen Link zu sehen.
-
Diesem Atmel-SID hatte ich doch vor ein paar Jahren mal die "richtige Taktung" beigebracht - nachdem ich den entscheidenden Hinweis gegeben habe, dass man das Phi2-Signal mit auskodieren muss, sind die nervigen Fehlübertragungen weg gewesen. Und seit dem haben die SwinSID-Leute nichts gelernt? Im C16/C116/plus4 würde ein transparentes Latch (LS373 oder 573) die Haltezeit der Daten ausreichend verlängern. IRQ über SID-Select würde ich so beibehalten. Die Gleichungen von "Solder" sehen auch gut aus. Ich frage mich nur, warum er die MUX/2-Schaltung nicht mit in das Gal aufgenommen hat? Da sind doch noch Pins frei!
Jens
-
Da musst Du ihn wohl selbst fragen
Mein Bruder hat seinerzeit ganz aufs GAL verzichtet und alles auf HCT TTL aufgebaut, weil erstens keine Möglichkeit nen GAL zu beschreiben und 2. alles nötige in der Grabbelkiste lag. Das erste Ergebniss war ähnlich dessen von Cbmhardware, dann gings ans optimieren, zwischendurch noch paar ATI auf Apple umflashen um die SIDs finanzieren zu können *gg* -
Was ist damit? Hab ich Bitte melde dich an, um diesen Link zu sehen. gefunden.
-
offensichtlich exakt das gleiche wie in dem andren link schon
-
Korrekt
Übersehen.
Wo liegt nun die Schwierigkeit das Ding 1:1 nachzubauen? -
Gar keine Schwierigkeit, wo doch das Jedec vom GAL eh bekannt ist.
Aber wirklich interessant wäre es nur, mehrere etablierte Erweiterungen zusammen in einem Modul zu bringen. Siehe auch den Beitrag Bitte melde dich an, um diesen Link zu sehen.
-
Nachbauen, SwinSID reinstöpseln und schauen, ob er gleich auf Anhieb lüppt, was bei sauberer Nachbildung sehr warscheinlich ist. Lasst mal Ergebnisse hören, bin bissele neugierig.
-
Wo liegt nun die Schwierigkeit das Ding 1:1 nachzubauen?
Das Problem ist nach wie vor jemanden zu finden, der das Equipment hat um GALs zu programmieren, und das auch tun würde... -
dann fragt doch einfach mal guenner... der kann doch gals programmieren. und da gibts sicher auch noch zig andere hier im forum.
-