SID-Player ARM/FPGA?

[Mampf F. (mampf)]

Guten Morgen,

hab gegoogelt und bin über mehrere Projekte/Libs gestolpert, die den SID 
emulieren.

- resid
- resid_fp
- siduino
- fastsid aus dem Emulator Vice

Resid scheint für einen ARM viel zu aufwändig zu sein (Zyklengenaue 
Emulation).  Siduino ist sehr minimalistisch, aber vom Ergebnis wohl 
garnicht so übel. Über FastSID weiß ich nicht viel, muss ich 
ausprobieren.

Dann gibt es wohl noch SwinSID als Drop-In-Replacement für den 6581er 
... Die verwenden einen ATMega8 und der scheint wohl gut genug zu sein, 
aber kein Source-Code dafür.

Kennt jemand noch andere SID-Emulator-Projekte, die sich für eine 
ARM-Portierung eignen würden?

VG
Mampf

[chris (Gast)]

SID Sourcen für die Atmega gibt es einige, auch für einen Arduino Uno.

Wird es ein Open-Source Projekt?

[Mampf unterwegs (Gast)]

chris schrieb:
> SID Sourcen für die Atmega gibt es einige, auch für einen Arduino
> Uno.
>
> Wird es ein Open-Source Projekt?

Jup klar, ich halte nichts von closed source :)

Und natürlich nicht-kommerziell

[Mampf F. (mampf)]

Ah das Problem ist ja noch interessanter und geht über eine 
SID-Emulation hinaus ...

Man benötigt zum Abspielen der .sid-Files wohl auch noch eine 
6502-Emulation ... Kranker Scheiß xD

[Cyblord -. (cyblord)]

Was zum Geier ist SID?

[Mampf F. (mampf)]

Cyblord -. schrieb:
> Was zum Geier ist SID?

Der Sound-Generator vom C64 ...^^

Hmm, es gibt eine synthetisierbare Version des SIDs in VHDL ... 
6502-CPUs gibt es auch genügend ... Dazu noch einen Soft-Cortex-M0 und 
voila ...^^

Glaub ich hab mein nächstes Bastelprojekt ;-)

[Besucher (Gast)]

Mampf F. schrieb:
> Ah das Problem ist ja noch interessanter und geht über eine
> SID-Emulation hinaus ...
>
> Man benötigt zum Abspielen der .sid-Files wohl auch noch eine
> 6502-Emulation ... Kranker Scheiß xD

Wenn du mehr als nur die 08/15 SIDs abspielen möchtest (also z.B. auch 
x-fach Speed Tunes oder Digis) wirst du womöglich auch noch Teile des 
VICs (für Rasterinterrupts), Teile der CIAs (für Timerinterrupts) und 
die MMU emulieren müssen. An sich alles kein großes Problem, aber es 
kostet halt ordentlich Resourcen. Da möchte ich mal zu einem ARM mit 
wenigstens 150 MIPS raten. Zuzüglich einem separaten SID. ^^

PS: Wenn du das Projekt tatsächlich angehst dann halte uns bitte auf dem 
Laufenden! Ich wollte auch schon immer einen SID-Player für die 
Stereoanlage haben, bin die Sache aber irgendwie nie tatsächlich 
angegangen...

[Andreas R. (daybyter)]

Kennst das schon?

http://www.fpgasid.de/project-definition

[Mampf F. (mampf)]

Andreas R. schrieb:
> Kennst das schon?
>
> http://www.fpgasid.de/project-definition

Nice, allerdings gibt es da keine Sourcen dazu :'(

Besucher schrieb:
> wirst du womöglich auch noch Teile des
> VICs (für Rasterinterrupts), Teile der CIAs (für Timerinterrupts) und
> die MMU emulieren müssen.

Puh, also einen ganzen C64 quasi ... Und das nur um Sid-Files 
abzuspielen xD

Hmm, da würde ich mich eher an sidplay(fp) orientieren ... Das scheint 
ein recht guter Player zu sein und es würde mich fast wundern, wenn der 
auch noch eine VIC, CIA und MMU-Emulation hat :)

 ... Ich hab zufällig gerade ein Board mit STMF4 designed. Der läuft auf 
168MHz und hat 32MB RAM, µSD-Slot, I2S Stereo DAC - und als Display eine 
Wortuhr xD Ah und ist 80x40mm groß in etwa.

Aber ich geh fest davon aus, dass der wahrscheinlich zu langsam sein 
wird. Insbesondere sidplay mit der Zyklus-genauen Emulation. Irgendwie 
müssen die Zyklen@9,irgendwas-MHz ja durchgerechnet werden ...

Danach kuck ich mal weiter ... Wahrscheinlich macht eine FPGA-Version 
eher Sinn :)

[Mampf F. (mampf)]

Ahja der absolute Wahnsinn!

Die libsidplay hat tatsächlich eine VIC, CIA, ... Emulation!

Auszug aus dem Code:

/ Set the ICs environment variable to point to
// this player
Player::Player (void)
// Set default settings for system
:CoUnknown<ISidplay2>("SIDPlay 2"),
 CoAggregate<ISidTimer>(*iaggregate()),
 c64env  (&m_scheduler),
 m_scheduler ("SIDPlay 2"),
 cpu     (&m_scheduler),
 xsid    (this),
 cia     (this),
 cia2    (this),
 sid6526 (this),
 vic     (this),

Zwar alles abgespeckt - ist irgendwie klar, eine grafische Ausgabe zB 
braucht man nicht - aber trotzdem vorhanden.

Erwähnte ich schon mal? Kranker Scheiß xD

[Besucher (Gast)]

Mampf F. schrieb:
> Ahja der absolute Wahnsinn!
> Die libsidplay hat tatsächlich eine VIC, CIA, ... Emulation!

Dürfte wohl daran liegen das bisher noch niemand ein hinreichend 
flexibles Dateiformat (auf dem PC) für SIDs erfunden hat. :)  Deswegen 
werden Besonderheiten von Tunes noch immer mit Hilfe von C64-nativem 
Wrapper-code gelöst. Und dieser ist zumeist einfach gehalten (nutzt 
bspw. Raster- oder Timer-Interrutpts), schon allein um sowohl auf PAL- 
als auch auf NTSC- Geräten zu laufen. Und natürlich sollen die SIDS ja 
auch nicht nur auf PC-Playern laufen sondern vor allem auch auf einem 
normalen C64.
Die Jungs von der HVSC geben sich zwar redlich Mühe die Sammlung 
möglichst "Emulations-kompatibel" zu halten (haben ja z.B. auf PSIDv2NG 
umgestellt), aber da dies bisweilen Handarbeit für jedes einzelne 
Musikstück erfordert darf man da auch nicht zu viel erwarten.

Jetzt wäre es freilich interessant zu wissen wieviele der Tunes denn 
nun welche Features von VIC/CIA/MMU benötigen um abgespielt zu werden. 
Ich weiss noch, ich hatte mal angefangen einen Emulator zu schreiben nur 
um genau diese Informationen herauszubekommen (und um anschließend 
selber einen Standalone-Sidplayer zu bauen). Aber irgendwie ist das 
Projekt im Sande verlaufen... Muss mal nachschauen wie weit ich da 
gekommen war.
Auf VIC/CIA/MMU verzichten wollen würde ich allerdings nicht, denn 
dadurch würde ein großer Teil hervorragender Musikstücke wegfallen. 
Soviel Luxus muss schon sein. :)

Hmm, ich habe schon mehrere - mehr oder weniger rudimentäre - 
c64-Emulatoren für verschiedene Zwecke geschrieben und mich auch schon 
mehr als einmal mit dem Projekt eines Standalone-Sidplayers befasst. Aus 
der groben Erinnerung weiss ich noch das ich den Resourcenbedarf einer 
MCU dafür beim ersten Mal mit 180 MIPS abschätzte, beim zweiten Mal mit 
150 MIPS (jeweils mit separatem SID-Chip, also ohne Emulation dieses 
Chips (was für die Goldohren unter uns ja ohnehin untragbar wäre...)). 
Ich kann mich allerdings nicht mehr daran erinnern wie diese 
Abschätzungen zustande kamen. xD  (mit/ohne Ansteuerung von 
SD-Card/LCD/XMEM/etc. ?)


PS: Ach, ich schicke dir nachher mal einfach 'ne PM.

[Besucher (Gast)]

Mampf F. schrieb:
> Man benötigt zum Abspielen der .sid-Files wohl auch noch eine
> 6502-Emulation ... Kranker Scheiß xD

Beside: Genau genommen muß eine 6510-CPU emuliert werden. Diese hat ggü. 
einer 6502 noch einen zusätzlichen Port (8 Bit) über den u.a. auch die 
MMU gesteuert wird. Und da der c64 normalerweise in ca. 90% aller 
Taktzyklen über die CPU (und somit auch über die MMU) auf den Speicher 
zugreift wird eine exakte Emulation der CPU+MMU in Software richtig 
teuer...
Eine 100%ig exakte Emulation (welche ja auch Halbzyklen, Badlines und 
ähnliche Späße berücksichtigen müsste) würde für einen SID-Player imho 
allerdings nicht benötigt, da reicht es aus in maximal ca. 25% aller 
Taktzyklen die MMU zu berücksichtigen. Dadurch wird die Sache schon 
wesentlich billiger. :)
Und wenn man mal davon ausgeht das nicht mal die Goldohren unter uns 
eine Verzögerung von wenigen µS heraushören können dann kann man damit 
durchaus arbeiten. :D

[Markus (Gast)]

Das Discovery Board wäre gut für einen Player geeignet, weil es schon 
einen Codec hat:
http://www.st.com/en/evaluation-tools/stm32f4discovery.html

[Mampf F. (mampf)]

Markus schrieb:
> Das Discovery Board wäre gut für einen Player geeignet, weil es
> schon
> einen Codec hat:
> http://www.st.com/en/evaluation-tools/stm32f4discovery.html

Aber kein SDRAM und kein SD-Slot ... Zufällig hab ich gestern erst ein 
Board fertig gebastelt, das zufällig perfekt dafür wäre xD

Ein STM32F429 @ 168MHz mit 32MB SDRAM, µSD-Slot und einem Audio-Codec - 
auf ca 80*40mm :D

Auf dem Ding werde ich das Sid-Zeugs ausprobieren :)

(Eigentlich war das Ding dazu gedacht, den Cris-Dynamic-Compressor 
(ursprünglich ein Audacity Plugin in lisp) drauf laufen zu lassen ... 
Der macht aber einen wahnsinnigen Lookahead von bis zu 17 Sekunden, 
weshalb man da viel RAM braucht zum Buffern)

SDRAM funktioniert wunderbar, heute muss ich noch µSD und Audio testen 
... Auf die SD könnte man die ROMs für Kernal, Chargen und Basic 
auslagern und dann in den SDRAM laden :)

(Und als Display gibt es eine zweite Platine mit einer Wortuhr xD )

[Markus (Gast)]

>Aber kein SDRAM und kein SD-Slot ...
Ja, das ist ein echter Nachteil an dem Board.

Eine alternative wäre das
Beitrag "STM32F407 Black und Arduino"
das ist günstig und hat einen SD-Kartenslot.
Es gibt ja dort auch eine Variante für zusätzliches RAM.

Dazu dann noch den Adafruit I2S Verstärker
https://www.adafruit.com/product/3006

oder das STM32F7 Dicovery. Das hat alles inclusive Display

http://www.st.com/en/evaluation-tools/32f746gdiscovery.html

ist aber ein wenig kostenintensiv.

[Mampf F. (mampf)]

Puh, kleiner Zwischenstatus ... SDRAM, µSD und USB (MSC) funktioniert 
... Hab die C64-Kernel jetzt auf die SD-Karte gepackt ... Mal schauen, 
ob ich morgen zum Portieren der libsidplay komme :D

Wahrscheinlich ist der ARM sowiso viel zu langsam, aber mal kucken ;)

[Marco H. (damarco)]

Was sich ideal dazu eigen sind die Xmos µP es gab sogar mal ein Projekt 
hierzu.

https://www.youtube.com/watch?v=NgI3g1nkkoI

Ein ähnliches Board bekommt man für 14-50€ :).

http://www.pollin.de/shop/dt/NzIzNzkyOTk-/Bauelemente_Bauteile/Entwicklerboards/Raspberry_Pi/Entwicklerboard_XMOS_XK_STK_A8DEV_XCORE_XS1_A.html

Die 500MIPS sollten reichen ;)

[Michael H. (dowjones)]

Mampf F. schrieb:
> Puh, kleiner Zwischenstatus ... SDRAM, µSD und USB (MSC) funktioniert
> ... Hab die C64-Kernel jetzt auf die SD-Karte gepackt ... Mal schauen,
> ob ich morgen zum Portieren der libsidplay komme :D
>
> Wahrscheinlich ist der ARM sowiso viel zu langsam, aber mal kucken ;)

PM hatte wegen der Captchas leider nicht geklappt... Also falls die 
Rechenpower für libsidplay nicht reicht und du dich dazu entschließen 
solltest selber eine Emulation zu schreiben dann sag doch mal Bescheid. 
Daran könnte ich mich glaube ich gut (und würde das auch gerne) 
beteiligen. :)

Marco H. schrieb:
> 
http://www.pollin.de/shop/dt/NzIzNzkyOTk-/Bauelemente_Bauteile/Entwicklerboards/Raspberry_Pi/Entwicklerboard_XMOS_XK_STK_A8DEV_XCORE_XS1_A.html
>
> Die 500MIPS sollten reichen ;)
Schickes Board! Und immer noch billiger als ein richtiger SID bei ebay. 
xD

[Marco H. (damarco)]

Das Stimmt ich habe auch noch welche im Schrank ;) Es gab mal jemanden 
der hat die Dinger Stangenweise geerbt. Auch noch andere Sachen aus der 
Zeit.

Da sie bei einigen Musikern recht beliebt sind ist der Preis zur 
Innovation recht hoch.  Bei solchen Geschichten geht es er darum 
legendäre Dinge mit heutiger Technik nach zubauen.

Es gibt heute noch Software für den C64, man mag es kaum glauben :)

Die Xmos µP sind für alle Zeitkritischen Sachen recht interessant.

[H.Joachim S. (crazyhorse)]

Hatte der Amiga500 den gleichen Chip? In meiner Wunderkiste waren auch 
ein paar Stangen "Amiga500 SID" dabei, muss gleich mal suchen gehen, was 
das genau war. Vielleicht Goldstaub :-)

[Michael H. (dowjones)]

H.Joachim S. schrieb:
> Hatte der Amiga500 den gleichen Chip?
Leider nicht. Der Amiga hatte afaik einen Chip namens Paula welcher 
PCM-Samples per DMA abspielte.
Aber falls du da tatsächlich noch eine Kiste mit SIDs im Keller hast 
dann sag Bescheid!! :D

[H.Joachim S. (crazyhorse)]

Ich schau morgen mal nach. Das waren auf jeden Fall DIL-ICs. Paula ja 
PLCC.

[Mampf F. (mampf)]

Michael H. schrieb:
> und du dich dazu entschließen
> solltest selber eine Emulation zu schreiben dann sag doch mal Bescheid.

Interessant wäre es schon, ich tu mich aber meistens recht schwer damit, 
mit irgendetwas länger als 2 Wochen beschäftigt zu sein^^

Wenn die Rechenpower nicht reicht, würde ich gleich Richtung FPGAs gehen 
:)

Aber danke für dein Angebot! :)

[Andreas R. (daybyter)]

Die Weiterentwicklung des SID findet man wohl hier:

http://mega65.org/

(mit Stereo und so)

[Michael H. (dowjones)]

Mampf F. schrieb:
> Michael H. schrieb:
>> und du dich dazu entschließen
>> solltest selber eine Emulation zu schreiben dann sag doch mal Bescheid.
>
> Interessant wäre es schon, ich tu mich aber meistens recht schwer damit,
> mit irgendetwas länger als 2 Wochen beschäftigt zu sein^^

Ach, das kenne ich... Ist aber kein Problem, bei deinem Tempo würde ein 
c64-Emulator ja locker in einer Woche fertig sein. ^^

> Wenn die Rechenpower nicht reicht, würde ich gleich Richtung FPGAs gehen
> :)
Mit FPGAs kenne ich mich leider zu wenig aus um dabei mithalten zu 
können. :/  Für etwaige Detailfragen zu einer Emulation stünde ich 
jedoch zur Verfügung.
Und wenn der SID-Player steht dann baue bitte auch gleich noch einen 
MOD-Player mit ein! xD

H.Joachim Seifert schrieb
>Ich schau morgen mal nach. Das waren auf jeden Fall DIL-ICs. Paula ja
>PLCC.

Ich harre gespannt deines nächsten Postings. :D

[Mampf F. (mampf)]

Andreas R. schrieb:
> Die Weiterentwicklung des SID findet man wohl hier:

Sehr cool! Der C65 ? Leider kenn ich den nur von Bilder, war aber 
damals, als man zum ersten mal was davon las, aber schon sehr fasziniert 
:)

Aaaah, die haben eine quelloffene VHDL-Implementierung u.a. vom SID!

Dann gibt es wohl schon zwei ... Muss ich mal vergleichen :)

https://github.com/MEGA65/mega65-core/blob/master/src/vhdl/sid_6581.vhd


Michael H. schrieb:
> Für etwaige Detailfragen zu einer Emulation stünde ich
> jedoch zur Verfügung.

Darauf komme ich sicher zurück!

z.B. hatte ich einen Quelloffenen SID-Core gesehen und in einem Thread 
meinte jemand, es würde irgendeine Synchronisierung fehlen ... Evtl 
würde ich daran noch was weiterbasteln.

Was man dann auch brauchen könnte sind anspruchsvolle SID-Files, die den 
SID auch richtig nutzen und die Features kombinieren. Hatte da mal ein 
Youtube-Video mit so einem SID-Sound gesehen, muss ich nochmal suchen :)

Michael H. schrieb:
> Und wenn der SID-Player steht dann baue bitte auch gleich noch einen
> MOD-Player mit ein! xD

OMG, die MOD-Files hatte ich ja total vergessen! Vielen Dank für die 
Erinnerung!

[Mampf unterwegs (Gast)]

Nur ganz kurz... Ich glaube das mit dem. Stm32 könnte in echtzeit 
klappen.... Hab die libsidplay und resid auf dem arm laufen und für 
10sek abspielzeit braucht er in etwa 6sek... Leider konnte ich noch 
nicht reinhören, aber daten sind zumindest vorhanden... Spannend xD

[Markus (Gast)]

>Nur ganz kurz... Ich glaube das mit dem. Stm32 könnte in echtzeit
>klappen....

Das klappt mit Sicherheit in Echtzeit. Ein Atmeg16 schafft des SID schon 
in C ohne besondere Assemblertricks. Und der 6502 Simulator läuft mit 
Sicherheit auch.

[Besucher (Gast)]

Das sind ja schonmal gute Neuigkeiten! :)
War es denn ein Standard-Tune (der um die 5%-10% der Rechenzeit des c64 
nutzt) oder schon etwas "anspruchsvolleres"?

[Andreas R. (daybyter)]

Frag doch mal im forum64.de

[Mampf F. (mampf)]

Besucher schrieb:
> Das sind ja schonmal gute Neuigkeiten! :)

hah, ich hab gestern rein gehört ... total kaputt alles xD

Ich probier es nochmal, hab mit den Defines möglicherweise was kaputt 
gemacht ... Lass die Lib jetzt erstmal für arm-linux cross-compilen und 
übertrage dann die Defines :)

[Markus (Gast)]

Mampf
>Nur ganz kurz... Ich glaube das mit dem. Stm32 könnte in echtzeit
>klappen....

Du könntest den Code so kapseln, dass man ihn auf unterschiedlichen 
Frameworks laufen lassen kann.

1. Audiobuffer mit Funktion update(&AudoBuffer[0]) füllen
2. Schnittstellen zu Speicherkarten mit Call-Backs kapseln.

[Mampf F. (mampf)]

Sooo, es geht doch ...

Bin mir noch nicht 100% sicher ... Aber für 60sek@22.05kHz hat er 40sek 
benötigt, für 44.1kHz könnte es gerade nicht ausreichen ... Aber ich hab 
noch Möglichkeiten ... SDRAM-Initialisierung tweaken, Timings anpassen, 
Sektionen ins SRAM auslagern - zB die 6502/10-Emulation ...

Hmm, ob man MP3s hier überhaupt hochladen kann ... Mal ausprobieren :)

Hat jemand ein anspruchsvolles SID-File?

Kenn mich da leider zu wenig aus^^

[Mampf F. (mampf)]

Markus schrieb:
> Du könntest den Code so kapseln, dass man ihn auf unterschiedlichen
> Frameworks laufen lassen kann.
>
> 1. Audiobuffer mit Funktion update(&AudoBuffer[0]) füllen
> 2. Schnittstellen zu Speicherkarten mit Call-Backs kapseln.

Der sidplayer ist erstaunlich pflegeleicht ...

Das hier ist alles, was man im Prinzip braucht, um Files abzuspielen:

// einfach irgendwie ein SID in das RAM laden (FsFAT)
    f_open(&MyFile, "MEGA.SID", FA_READ);
    uint32_t size = f_size(&MyFile);
    uint8_t *sidfile = (uint8_t*) malloc(size);
    f_read(&MyFile, sidfile, size, (UINT*)&bytesread);
    f_close(&MyFile);

// hier gehts mit dem SID los
    sidplay2 Sidplay2;

    SidTune Tune(sidfile, size);
    ReSIDBuilder ReSID("");
    Tune.selectSong(1);
  
    Sidplay2.load(&Tune);
    sid2_config_t sid2config;
    ReSID.create(1);
    sid2config.frequency = 22050;
    sid2config.emulateStereo = true;
    sid2config.leftVolume = 255;
    sid2config.rightVolume = 255;
    sid2config.clockSpeed = SID2_CLOCK_PAL;
    sid2config.optimisation = 1;
    sid2config.sampleFormat = SID2_BIG_UNSIGNED;
    sid2config.sidModel = SID2_MOS6581;
    sid2config.forceDualSids = false;
    sid2config.sidSamples = true;
    sid2config.playback = sid2_stereo;
    sid2config.environment = sid2_envPS;
    sid2config.precision = 16;
    sid2config.sidEmulation = &ReSID;
    Sidplay2.config(sid2config);

    uint8_t *output = (uint8_t*) malloc(22050*2*2);

// abspielen und mit dem output dann irgendwas machen
    for (int i=0;i<60;i++) {
      Sidplay2.play(output, 22050*2*2);
    }

D.h. man braucht kein wahnsinniges Framework ... :)

Was auf jedenfall dazu kommt - ohne macht es keinen Sinn ist ein 
Buffering und DMA, um die Daten aus den Speicher auf die I2S zu 
schaufeln :) Mal kucken, vlt krieg ich das Montag schon hin ;-)

[Mampf F. (mampf)]

Hah, DMA und I2S funktioniert auch ... Sogar angenehme 
Kopfhörerlautstärke ;-)

Somit ist mein Board vollständig getestet und funktioniert :)

Jetzt muss ich mal anspruchsvolle SIDs suchen ... Ich mach nachher noch 
eine Aufnahme :)

[Mampf F. (mampf)]

So noch ein Sample ... Über den Audio In meines PCs aufgenommen ... So 
ein Mist wieder, das hat unter Linux nicht gescheit funktioniert ... der 
PC hat zu leise, in der falschen Samplerate und einer der beiden Kanäle 
hatte eine Dauerhochfrequenzstörung mit Amplitude maximal ... Das lag 
aber nicht am ARM, das hatte der auch, wenn ich ihn abgesteckt hatte xD 
Hoffe, die Qualität geht nach Normalisieren und Resamplen ;)

Das hat der STM32 in Echtzeit abgespielt :)

[Markus (Gast)]

Welches Framework hast du denn jetzt genommen ?

[Michael H. (dowjones)]

Mampf F. schrieb:
> Das hat der STM32 in Echtzeit abgespielt :)
Das klingt ja schon topfit! :D

Probier mal die angehängten SIDs, die sollten überdurchschnittliche 
Rechenzeit benötigen. Wenn die auch laufen wie sie sollen - dann 
Respekt!!

[Mampf F. (mampf)]

Markus schrieb:
> Welches Framework hast du denn jetzt genommen ?

Mein Projekt hab ich per CubeMX von ST erstellen lassen, also HAL. CMSIS 
alleine wär zwar schöner gewesen, aber da ist die ST-Peripherie ziemlich 
frickelig und aufwändig - USB zB.

Hoffe, ich hab deine Frage richtig verstanden.

Michael H. schrieb:
> Probier mal die angehängten SIDs, die sollten überdurchschnittliche
> Rechenzeit benötigen. Wenn die auch laufen wie sie sollen - dann
> Respekt!!

Probier ich gleich mal aus :)

[Markus (Gast)]

>Hoffe, ich hab deine Frage richtig verstanden.

Ähm, ich meinte eher, welchen SID-Player hast Du genommen? Hast Du 
vielleicht einen Link zum Source?

[Mampf F. (mampf)]

Markus schrieb:
>>Hoffe, ich hab deine Frage richtig verstanden.
>
> Ähm, ich meinte eher, welchen SID-Player hast Du genommen? Hast Du
> vielleicht einen Link zum Source?

Aaaah, ich hab sidplay2 verwendet ... Bei dem ist der resid gleich dabei 
(ich glaube, eine der akkuratesten Sid-Emulationen überhaupt).

https://sourceforge.net/projects/sidplay2/

(ausprobieren kann man den zB unter Linux über den sidplay ... Der ist 
glaub ich direkt im Repository)

So, die SIDs getestet ... Also für 44kHz wäre die 4fache 
Prozessorleistung hilfreich - und die anspruchsvollen Sids laufen bei 
22kHz nicht mal in Echtzeit.

Aaaaber, ich hab noch nicht zum optimieren angefangen ... Ein Bottleneck 
könnte mein SDRAM sein ... resid hat ein paar Arrays, die meinen ganzen 
internen RAM auffressen und so musste quasi fast alles andere ins SDRAM 
... Und den Code kann ich deshalb auch nicht im SRAM auslagern, Muss mal 
schauen, wieso die Wave-Tables nicht als "const" deklariert sind ... Ob 
man die ändern kann?

[Mampf F. (mampf)]

Soooo, also ... Fazit meines kleinen Tests ... Die 168MHz sind 
ungenügend und der STM32F429 mit 1MB Flash und 192kB (internes) RAM ist 
zu klein. (Evtl mit dem STM32H7 nochmal testen ... Der hätte 400Mhz ist 
aber noch nicht erhältlich, aber den gibt es dann auch im TQFP144!)

Die Wave-Tables müssen im internen RAM liegen, sonst wird das Ganze 
nochmal deutlich langsamer. Aber dann ist nicht mehr genügend RAM 
übrig,um Code in den RAM auszulagern. Und die restlichen Variablen, die 
resid und libsidplay anlegen sprengen diesen auch.

Aus dem SDRAM ist es zu langsam.

Also alles in allem ein netter Test, aber nicht wirklich tauglich ...

War aber keine Zeitverschwendung - hab die Gelegenheit genutzt, mein 
Board fertig zu testen und die Peripherie wie DMA und I2S in Gang zu 
bekommen.

Ich orientier mich jetzt neu und werde das demnächst nochmal als 
FPGA-Cores testen. Hab im Prinzip alles zusammengesammelt, was ich dafür 
brauche (leider gibt es keinen GPL-Core für den VIC, d.h. ich müsste 
einen verwenden, den man nicht redistributen darf - egal ob mit oder 
ohne Änderungen daran).

Ich könnte vmtl einen selbst bauen, aber da müsste ich mich erstmal 
einarbeiten, was die sid-music überhaupt vom VIC benötigt und das auf 
das allernötigste Reduzieren, da ich ja keine Grafikausgabe brauche - 
oder kucken, was die libsidplay mit dem VIC und der CIA macht und den 
C-Code nach VHDL portieren ... Da ist mir der Schwierigkeitsgrad aber 
noch nicht klar ... Muss ich mir mal anschauen :)

Eine GPL-Version der CIA hab ich auch nicht gefunden.

6510, SID und der PLA scheinen kein Problem zu sein, wobei man den SID 
vmtl noch mit FIR-Filter aufbohren müsste ... Das wäre aber vmtl eine 
kleinere Finger-Übung.

Frustrierend ist aber, dass jegliche komplett-Projekte eines C64igers 
als Core im FPGA nicht frei sind ... Da sitzen irgendwelche 
kommerzgeilen Leute auf ihren Cores und veröffentlichen den Bitstream 
für den FPGA. Oder eben eine Version, die Quellcode hat, aber mit dem 
man nichts machen darf. ("The source-code (VHDL) of FPGA-64 is made 
available strictly for personal educational purposes. It is not allowed 
to copy, upload or redistribute this work in any way, neither in 
original form nor with additional files or changes. Contact the author 
if you want a commercial license for (part of) FPGA-64.")

Schade ... Aber gut, wie kompliziert kann so eine uralt-Kiste schon 
sein, das Wissen ist verfügbar, man muss nur kucken wo ... Ansonsten ist 
es ja straight forward ... Ich denke, die CPU, SID, PAL und Speicher 
kriegt man recht schnell hin ... VIC und CIA wird interessant. (*edit*: 
Oh, die Minimal-VIC-Implementierung ist ja wirklich sehr kurz ... Und 
die Event-Loop ist als State-Machine implementiert ... Dann glaub ich 
ist das kein Problem mit VHDL).

[Markus (Gast)]

>Soooo, also ... Fazit meines kleinen Tests ... Die 168MHz sind
>ungenügend

Sehr schade. Hast Du Lust das Projekt hier zu posten, dann könnte man 
mal einen Blick darauf werfen.

[Markus K. (markus-)]

Mampf F. schrieb:
> Soooo, also ... Fazit meines kleinen Tests ... Die 168MHz sind
> ungenügend und der STM32F429 mit 1MB Flash und 192kB (internes) RAM ist
> zu klein. (Evtl mit dem STM32H7 nochmal testen ... Der hätte 400Mhz ist
> aber noch nicht erhältlich, aber den gibt es dann auch im TQFP144!)

Die F7 gibts mit bis zu 512KB internem RAM, sie sind deutlich schneller 
als die F4 und sie haben Caches, was den Zugriff aufs SDRAM (je nach 
Anwendung) auch beschleunigen kann. Außerdem sind sie natürlich 
lieferbar.

Beim H7 sollte man beachten, dass nur der Core und das tightly coupled 
memory mit 400MHz laufen, die SRAM1..3 dagegen nur mit 200MHz.

[Marco H. (damarco)]

RPI mit bare metal, wäre auch noch möglich.

[Mampf F. (mampf)]

Markus schrieb:
> Sehr schade. Hast Du Lust das Projekt hier zu posten, dann könnte man
> mal einen Blick darauf werfen.

In der "unpolished" Version sicherlich :)

Marco H. schrieb:
> RPI mit bare metal, wäre auch noch möglich.

Hmm, ja, der hätte sicherlich genügend Resourcen :)

Persönliches Problem ist allerdings, ich mag nicht sonderlich gerne 
kauf-Module^^ Ich weiß, ist nicht wirtschaftlich, aber ... naja^^

Ich hab mich mit dem FPGA-Thema mal beschäftigt ... Wenn man den VIC 
wirklich auf das Minimum reduziert wie in der libsidplay, wird alles 
extrem vereinfacht.

Das, was mir nicht so in bestehenden Projekten gefallen hat, ist das 
Einbetten der ROMs direkt in VHDL als - ähm - ROM^^

Hab da ein uraltes damaliges Projekt gefunden, das evtl gut geeignet 
wäre ... Das hat 1MB SRAM (als 512k*16) und da könnte man das 
Memory-Mapping und das Bank-Switching des C64 gut umsetzen ... Der VIC 
muss ja vom RAM nicht lesen können, weshalb sich da vieles vereinfacht 
und man die Wahnsinns-PLA in der Form auch nicht braucht.

Mal schauen, wie weit ich mit einem uralt Spartan 2 komme xD

Falls der nicht reicht, hätte ich noch Alternativen wie das Altera DE1 
(hat auch 512kB SRAM)

[Markus (Gast)]

>In der "unpolished" Version sicherlich :)
Da ist jetzt aber nur das Bild von Deinem FPGA-Board ;-)

[Mampf F. (mampf)]

Markus schrieb:
>>In der "unpolished" Version sicherlich :)
> Da ist jetzt aber nur das Bild von Deinem FPGA-Board ;-)

Here you are ... Lass dich nicht von "mp3" irritieren, das man in 
einigen Filenamen findet ;-)

Da ist auch das cubemx-File dabei, dann sieht man, wo welche Peripherie 
dran hängt.

[Markus (Gast)]

>Here you are ...

Dankeschön :-)
Stecken da zwei SID-Emulatoren drinn? resid und libsidplay?

[Mampf F. (mampf)]

Markus schrieb:
>>Here you are ...
>
> Dankeschön :-)
> Stecken da zwei SID-Emulatoren drinn? resid und libsidplay?

Nope, ReSid ist die Sid-Emulation, Libsidplay macht die 6510, die CIA, 
die VIC und quasi die "Glue-Logic" dazwischen - und das ganze 
File-Handling (SID-Files laden, in den RAM an die richtige Stelle 
kopieren für die 6510 CPU usw ):) Der "SidBuilder" (bei libsidplay 
dabei) wrappt den ReSid so, dass das zu den anderen Emulierten Chips 
dazu passt.

[Markus (Gast)]

Danke.

>Die Wave-Tables müssen im internen RAM liegen, sonst wird das Ganze
>nochmal deutlich langsamer.

Was meinst Du mit Wave-Tables? Sollte der SID nicht den Sound 
produzieren?

Mich wundert, dass viele Dateien die Endung *.cc haben, das scheint mir 
heute ziemlich unüblich.

>wobei man den SID
>vmtl noch mit FIR-Filter aufbohren müsste ... Das wäre aber vmtl eine
>kleinere Finger-Übung.

Für was den FIR Filter?

Im Verzeichnis gibt es auch viele *.dat Datein. Für was sind die gut?

[Markus (Gast)]

>Soooo, also ... Fazit meines kleinen Tests ... Die 168MHz sind
>ungenügend und der STM32F429 mit 1MB Flash und 192kB (internes) RAM ist
>zu klein. (Evtl mit dem STM32H7 nochmal testen ... Der hätte 400Mhz ist
>aber noch nicht erhältlich, aber den gibt es dann auch im TQFP144!)

Was mir jetzt auch noch nicht ganz klar ist: Wie passt Dein Fazit zu dem 
mp3-File, welches Du gepostet hast?:
Beitrag "Re: [ARM] SID-Emulator-Library?"

[Andreas R. (daybyter)]

Mampf F. schrieb:
> Ich hab mich mit dem FPGA-Thema mal beschäftigt ... Wenn man den VIC
> wirklich auf das Minimum reduziert wie in der libsidplay, wird alles
> extrem vereinfacht.

Ja, das wäre aus meiner Sicht echt cool. Das liegt aber nur daran, 
dass ich ein cp/m Fan bin und mir ein VIC, der zum alten R3 kompatibel 
ist, echt helfen würde (die sind rar und eher teuer). Damit würde 
nämlich das z80 Modul bei mir wieder laufen (mein R3 ist kaputt 
gegangen).

Ebenso fänd ich es cool gleich eine 80-Zeichen Option und nen 
aktuelleren Ausgang (VGA wohl) zu implementieren. Dafür könnte ich wohl 
sogar etwas verilog beisteuern.

Aber: ich kann Dir sagen, dass bei so einem Projekt sich ungefähr 1000 
Leute melden würden, bei denen irgendeine Demo nicht läuft. Diese 
Demo-Coder haben ja leider diese Angewohnheit, in die VIC-Register 
irgendwelche 'illegalen' Werte reinzuschreiben, mit denen der VIC dann 
irgendwas macht, was von den Entwicklern so nie geplant war.

U.a. hier kannst Dir bisserl was zum Thema anhören:

https://www.youtube.com/watch?v=po9IY5Kf0Mo

Aber trotz allem sollte sich mal jemand trauen, sowas zu starten.
Echter Team-Geist halt (TEAM = toll, ein anderer machts).

:-)

[Mampf F. (mampf)]

Markus schrieb:
> Was meinst Du mit Wave-Tables? Sollte der SID nicht den Sound
> produzieren?

ReSid hat für die 4 verschiedenen Kurvenformen Tabellen, um diese zu 
generieren.

Markus schrieb:
> Mich wundert, dass viele Dateien die Endung *.cc haben, das scheint mir
> heute ziemlich unüblich.

Hmm ja, k.A. :)

Markus schrieb:
>>wobei man den SID
>>vmtl noch mit FIR-Filter aufbohren müsste ... Das wäre aber vmtl eine
>>kleinere Finger-Übung.
>
> Für was den FIR Filter?

Die VHDL-Implementierung des SIDs hat keine Filter ... Man kann dem SID 
ein paar Analog-Filter zuschalten (oder so ähnlich) und man müsste das 
in VHDL als digitalen Filter implementieren. FIR-Filter sind solche 
digitalen Filter, die sich leicht implmentieren lassen (wenn man die 
Filter-Koeffizienten hat). Das geht aber richtung digitale 
Signalverarbeitung und wurde deshalb vmtl nicht umgesetzt, weil das 
Thema ansich ziemlich komplex ist (und viele FPGA-Resourcen benötigt).

> Im Verzeichnis gibt es auch viele *.dat Datein. Für was sind die gut?

Ich vermute, das sind die binären Files, bevor sie in C-Code umgewandelt 
wurden.

Markus schrieb:
> Was mir jetzt auch noch nicht ganz klar ist: Wie passt Dein Fazit zu dem
> mp3-File, welches Du gepostet hast?:

Ja also mit meinem Fazit wollte ich nicht sagen, dass es garnicht 
funktioniert ... Aber es funktioniert nicht gut genug, dass man damit 
alle SID-Files abspielen könnte, die man wollen würde. Fast so wie ein 
MP3-Player, der nur bis 128kBit abspielen kann ... Den würde auch 
niemand wirklich haben wollen xD

Andreas R. schrieb:
> Ebenso fänd ich es cool gleich eine 80-Zeichen Option und nen
> aktuelleren Ausgang (VGA wohl) zu implementieren. Dafür könnte ich wohl
> sogar etwas verilog beisteuern.

Oh, da hast du mich falsch verstanden :)

Die Minimal-VIC-Implementierung soll vollständig ohne Grafik 
auskommen, d.h. hat nur die Register, die Raster-Counter, die 
Bad-Line-Erzeugung usw, aber keinerlei Grafikausgabe.

Die Bad-Lines sind beim C64 wichtig (alle 8 Zeilen muss der VIC die CPU 
anhalten, um Daten für die Textdarstellung aus dem RAM zu holen, das 
dauert so ca 40 Taktzyklen), da sich viel C64-Code auf das Timing 
verlässt und die Music vmtl timingtechnisch kaputt wäre, wenn man die 
Badlines nicht implementieren würde :)

Das FPGA64-Projekt hat eine komplette VIC-Implementierung:

http://www.syntiac.com/fpga64.html

Ist halt lizenztechnisch ein Albtraum, weshalb ich von dem Projekt 
nichts verwenden wollte - aber für deinen persönlichen VIC, könntest du 
da bestimmt was verwenden :)

[Mampf F. (mampf)]

Ah nice, hab noch ein Projekt gefunden, das OpenSource ist ...

Das hat noch eine CIA-Implementierung in VHDL :)

Dann hab ich alle Komponenten zusammen, die ich brauche und muss nur den 
Minimal-VIC basteln ...

https://github.com/gardners/c65gs

*edit*: Hab alle Cores - bis auf den Mini-Vic - mal synthetisieren 
lassen ... Vom Resourcen-Verbrauch wird das easy mit einem Cyclon 2 mit 
20k-LE ... 7% SID, 20% CPU, 2% CIA ... Der mini-VIC wird nicht viel 
brauchen ... Kriegt man locker unter - und gegen einen zweiten SID 
spricht nichts :D

[Markus (Gast)]

Hallo Mampf,

>Schade ... Aber gut, wie kompliziert kann so eine uralt-Kiste schon
>sein, das Wissen ist verfügbar, man muss nur kucken wo ...

die Formulierung liegt mir etwas schwer auf dem Magen. Ich habe da immer 
das Gefühl, dass die Leistungen der früheren Entwickler nicht richtig 
gewürdigt werden. Dabei waren das damals die Besten der Besten und sie 
haben Mannjahre mit der Entwicklung dieser Computer verbracht. Ich würde 
sagen:

"Diese uralt-Kisten sind sehr kompliziert"

Nehmen wir z.B. dein SID-Projekt für den STM32F4. Du hast SID-tunes 
Software , die für PCs mit mehreren Gigahertz und beliebig viel RAM 
geschrieben sind, auf einen STM32F4 mit 168MHz und begrenztem Speicher 
übertragen und dann heraus gefunden, dass die Leistung nicht ausreicht.

>Aber gut, wie kompliziert kann so eine uralt-Kiste schon sein
Und da genau kommt die Kompliziertheit ins Spiel: Man müsste nämlich die 
Komponente jetzt selber schreiben und auf den STM optimieren.

Ich schätze der SID-Code selbst kann mindestens um den Faktor 4 in der 
Laufzeit beschleunigt werden.

Die 6510 Simulation ist auch nicht Laufzeit-optimiert. Was möglich ist, 
wenn man einen Simulator wirklich optimiert, kann man hier im Projekt 
Beitrag "CP/M auf ATmega88" sehen.

Gut, es ist die Frage, ob man wirklich so viel Aufwand betreiben will um 
einen SID-Tune-Player auf dem STM zum laufen zu bekommen.

Nimmt man fertige Routinen, vereinfacht sich das Ganze natürlich 
ziemlich und da fällt mir das fälschlich Isaac Newton zugeschriebene 
Zitat ein:

"Wir alle stehen auf den Schultern von Riesen"

[Mampf F. (mampf)]

Markus schrieb:
> "Diese uralt-Kisten sind sehr kompliziert"

Kommt auf das Abstaktions-Level an, wie man sie betrachtet ...

Wenn man sich den VIC anschaut, dann ist das Ding furchtbar kompliziert.

Wenn man sich ansieht, wie die Komponenten verschaltet sind und die 
Chips nur als Blackboxen ansieht, vereinfacht sich das extrem.

Bei deiner Argumentation hast du eins nicht bedacht ... Die damaligen 
Entwickler waren alle genial und haben unglaubliche Leistungen 
vollbracht ... Trotzdem ist etwas bestehendes nachzuvollziehen oder gar 
nachzubauen wesentlich einfacher.

Meine Aussage schmälerte in keiner Weise die Leistung, die damals 
vollbracht wurden - vor alter Computer-Technik hab ich den höchsten 
Respekt (oder auch vor so Sachen wie dem Fernseher und der 
abwärtskompatiblen Erweiterung für die Farbe und die technische 
Umsetzung nur mit analogen Komponenten!)

Aber es ist nunmal so, dass vollbrachte Leistungen leichter repliziert 
werden können als etwas von Grund auf neu zu erfinden ... :)

> Gut, es ist die Frage, ob man wirklich so viel Aufwand betreiben will
> um einen SID-Tune-Player auf dem STM zum laufen zu bekommen.

Genau das ist der Punkt ... Evtl gibt es jemand, der den Ehrgeiz hat, 
das zu machen ... Ich gehöre da sicher nicht dazu - wenn etwas länger 
als 2 Wochen dauert, suche ich mir ein neues Projekt^^

> Nimmt man fertige Routinen, vereinfacht sich das Ganze natürlich
> ziemlich.

Genau, darauf wollte ich hinaus und meine Aussage war auf eine 
FPGA-Implementierung bezogen.

Ich hab fertige VHDL-Cores für 6502, CIA, SID und VIC (den ich 
allerdings so nicht verwenden werde) gefunden und die anzupassen und in 
ein VHDL-Projekt zu integrieren ist nicht besonders schwierig, da ich 
das meiste nur als Black-Boxen verwenden werde und sie nicht von Scratch 
neu bauen muss :)

Die PLA zB brauch ich so überhaupt nicht, wie sie im C64 war ... Mit 
VHDL ist man unabhängig vom Rest des C64, d.h. man muss auf vieles 
garnicht eingehen und es muss nicht kompatibel bleiben. Bisschen 
Adressdekodierung (wahrscheinlich sogar weniger, weil ich mit einem 
haufen SRAM verschwenderisch umgehen werde und so gut wie keine 
Adress-Dekodierung brauche, da ich keine zig verschiedenen Speicher habe 
sondern nur einen einzigen und dynamisches RAM hab ich auch nicht, das 
refresht werden müsste) und das war es dann im Prinzip, solange das 
Timing von CPU und VIC dann passt.

[Markus (Gast)]

Vor einiger Zeit habe ich mir diesen Video-Vortrag von einem der 
Entwickler bei Commodore angeschaut.
Die Inhalte des Vortrags sind wirklich gut:
Man bekommt einen guten Eindruck unter welchen Bedingungen ( sowohl 
technisch wie auch wirtschaftlich ) damals diese Home-Computer 
entwickelt wurden.

http://hackaday.com/2016/12/13/computers-for-the-masses-not-the-classes/

[Mampf F. (mampf)]

Markus schrieb:
> Vor einiger Zeit habe ich mir diesen Video-Vortrag von einem der
> Entwickler bei Commodore angeschaut.
> Die Inhalte des Vortrags sind wirklich gut:
> Man bekommt einen guten Eindruck unter welchen Bedingungen ( sowohl
> technisch wie auch wirtschaftlich ) damals diese Home-Computer
> entwickelt wurden.

Vielen Dank für das Video, das schau ich mir morgen gleich mal an!

Sowas finde ich hochinteressant! :)

Ah kleiner Zwischenstand zum FPGA-Dingens ... Ich bau gerade am Mini-VIC 
... Hab ein geniales Dokument gefunden, in dem das Timing steht und die 
"Hold"-Zeiten, in denen der 6510er nicht auf den Bus zugreifen darf.

http://unusedino.de/ec64/technical/misc/vic656x/vic656x-german.html

[Michael H. (dowjones)]

Dieser Artikel über den VIC ist in c64-Kreisen zwar bislang der 
Standart-Report schlechthin, allerdings dürfte der VIC bei einem 
SIDplayer nur eine sehr untergeordnete Rolle spielen. Es sollte reichen 
die aktuelle Rasterzeile in 0xd012/0xd011 sowie die zugehörigen 
Interrupts zu emulieren. Über etwaige Verzögerungen durch Badlines oder 
Sprites würde ich mir da überhaupt keine Gedanken machen*.

Die Emulation des 6510 wird wesentlich relevanter sein, und dafür kann 
ich - neben den alten Schinken von Synertek** - vor allem auch die 
Seite:
http://web.archive.org/web/20160315002735/http://homepage.ntlworld.com/cyborgsystems/CS_Main/6502/6502.htm
empfehlen!

Wünsche dir - auch aus eigenem Interesse xD - weiterhin viel Erfolg bei 
deinem Projekt! :D


* ich möchte mal behaupten das es Coder, damals wie heute, einen 
feuchten Kehrricht interessiert ob der Player ab und an mal für ein paar 
µS unterbrochen wird. xD
Solange man nicht weiss welchen Tracker der Musiker damals genutzt hat, 
und an welchen Taktzyklen der zugehörige Player dort vom VIC 
unterbrochen wurde, braucht man glaube ich gar nicht erst zu versuchen 
das Ganze auf µs exakt abspielen zu wollen. Das hört sowieso niemand 
heraus. Die Toleranzen des Analogteils vom SID (und seiner externen 
Beschaltung) sind schon alleine groß genug als das es hier wirklich 
nicht auf ein paar µS ankommt.

** http://archive.6502.org/datasheets/synertek_programming_manual.pdf
http://archive.6502.org/datasheets/synertek_hardware_manual.pdf

[Mampf F. (mampf)]

Michael H. schrieb:
> ch möchte mal behaupten das es Coder, damals wie heute, einen
> feuchten Kehrricht interessiert ob der Player ab und an mal für ein paar
> µS unterbrochen wird. xD

Naja, das ist schon einiges an Holz, was da abfällt ... Jede 8te Zeile 
um die 40 Taktzyklen + extra noch etwas, wenn Sprites aktiv sind :)

Ich kann mal testen, was passiert, wenn man in libsidplay das 
"BA"-Signal einfach deaktiviert :) Danke für die Idee!

Michael H. schrieb:
> Die Emulation des 6510 wird wesentlich relevanter sein

Für den hab ich mir bei OpenCores einen Core gesucht, der von sich 
selbst behauptet, er wäre zyklengenau :)

Also eigentlich war es 6502, den ich um den 6-Bit-Port, der über die 
Zeropage angesprochen wird, erweitern musste :)

Michael H. schrieb:
> Wünsche dir - auch aus eigenem Interesse xD - weiterhin viel Erfolg bei
> deinem Projekt! :D

Danke danke :)

Bin auch gut weitergekommen ... Den Minimal-VIC von libsidplay hab ich 
gestern nach VHDL portiert und quasi alles zusammen gebaut.

Synthese-Report anbei ... Passt locker (Mini-VIC, 6510, CIA1+2, inkl 2 
SIDs) in den FPGA des Altera DE1-Boards xD

Mit etwas Glück schaffe ich es heute noch, das Ganze zu testen :)

[Mampf F. (mampf)]

Heute auf Heise über den Monster-6502 :D

Sehr geiles Ding :)

https://www.heise.de/newsticker/meldung/Mehr-LEDs-MOnSter-6502-blinkt-wieder-3715460.html

[Markus (Gast)]

Ja, das Teil finde ich auch super. Am liebsten hätte ich eins.

Hier wurde ein Thread dazu angefangen:
Beitrag "6502 selfmade CPU"

[Mampf F. (mampf)]

Kennt jemand zufällig einen guten 6502 Disassembler für Linux?

Meine CPU läuft um Kreis ... Sie hat den Reset-Vector richtig aus dem 
RAM gelesen und ist an die richtige Stelle gesprungen, hat noch ein paar 
Befehle ausgeführt und hängt nun an einer Stelle:

$1f8e: jmp $1f8e

Ist wohl eine Art Fehler-Handler für irgendwas ... Nur mir ist nicht 
klar, weshalb sie dort hin kommt :)

[Mampf F. (mampf)]

Kleiner Zwischenstand ... Mein Problem von letztens war falsche 
Interrupts vom MiniVIC ... Hab einige Fehler in meiner Implementierung 
gefunden, dann kam zumindest schonmal Sound und ein Rythmus war 
erkennbar.

Jetzt hab ich festgestellt, der r6502_tc Core funktionierte nicht 
richtig, mit dem T65-Core hab ich zumindest Music, die noch (extrem) 
übersteuert ist, ansonsten funktionierts.

Dürfte nur noch eine Kleinigkeit sein, dann läuft es xD

[Mampf F. (mampf)]

Kleiner Zwischenstand ... Music hört sich jetzt in Ordnung an, aaaber 
hab da noch ein merkwürdiges Problem, das mit einige Zeit kosten wird, 
zu beheben ...

Die ersten 14 Sekunden oder so läuft die Musik viel zu schnell, bis sie 
dann plötzlich in der richtigen Geschwindigkeit läuft ... Keine Ahnung, 
wie das möglich ist. Evtl irgendeine Interrupt-Geschichte, aber so viele 
Interrupts gibt es da nicht und die CIA kann ich ausschließen (2 
unterschiedliche getestet, gleiches Ergebnis).

14 Sekunden sind halt echt seltsam ...

Kann jetzt noch versuchen, den MiniVIC durch einen anderen testhalber zu 
ersetzen, aber bei dem sollten die Interrupts korrekt sein ... Naja, mal 
schauen

[Michael H. (dowjones)]

Mampf F. schrieb:
> Kleiner Zwischenstand ... Music hört sich jetzt in Ordnung an,
:D

> Die ersten 14 Sekunden oder so läuft die Musik viel zu schnell, bis sie
> dann plötzlich in der richtigen Geschwindigkeit läuft ... Keine Ahnung,
> wie das möglich ist. Evtl irgendeine Interrupt-Geschichte, aber so viele
> Interrupts gibt es da nicht und die CIA kann ich ausschließen (2
> unterschiedliche getestet, gleiches Ergebnis).
Hmmmstimmt, es werden wohl nur die wenigsten SID-Files implizit 
Interrupts verwenden.
Wie werden die aus der Emulation herauskommenden Daten denn 
schlußendlich ausgegeben? Werden PCM-Samples errechnet und in einem 
Ringbuffer abgelegt, welcher dann per ISR abgespielt wird? Falls ja, 
vielleicht stimmt dort die Synchronisation erst dann wenn der Buffer 
vollgelaufen ist? Klingt etwas an den Haaren herbeigezogen, ich weiss, 
aber an irgendetwas muss es ja liegen. Und wenn es etwas naheliegendes 
wäre hättest du's ja wahrscheinlich schon längst gefunden... ;-)

[Mampf F. (mampf)]

Michael H. schrieb:
> Wie werden die aus der Emulation herauskommenden Daten denn
> schlußendlich ausgegeben?

Direkt als PCM-Audio-Samples :) Die werden direkt an den Audio-CODEC 
geschick.

Michael H. schrieb:
> Falls ja,
> vielleicht stimmt dort die Synchronisation erst dann wenn der Buffer
> vollgelaufen ist?

Hmm ... Irgendein Timing-Problem muss es sein ... Wenn ich meine 
Bus-Decoder-Logik ändere - zB auf Taktsynchron umstelle - dann bleibt 
das Phänomen nicht nur 14 Sekunden, sondern quasi für immer.

Also scheint es irgendwas mit der Buslogik zu tun zu haben, aber die 
Effekte sind mir völlig unverständlich.

Und soviele Möglichkeiten gibt es eigentlich nicht ... CIA1 und 2 hab 
ich von den Interrupts totgelegt, das Phänomen bleibt. Und der MiniVIC 
macht zumindest in der Simulation, was er soll. Und der VIC von FPGA64 
macht genau das gleiche (=Phänomen bleibt).

Interessanterweise macht es der andere CPU-Core auch nicht richtig, aber 
da ist die Geschwindigkeit nicht zu hoch, sondern viel zu langsam ... Da 
wird der SID nur kA alle halbe Sekunde mal mit neuen Werten gefüttert.

Also irgendwas ist grundlegend falsch und ich bin bisher noch nicht 
dahinter gekommen, was es ist.

Ich schau nochmal in das FPGA64-Projekt rein, evtl fällt mir da etwas 
auf, was dort anders als in meiner Implementierung gemacht wird :)

Und in der Arbeit hab ich ein Oszi, dann kann ich mir mal wirklich die 
Interrupts auf irgendwelche Pins ausgeben lassen und kucken :)

[Markus (Gast)]

Mampf F. schrieb:
> Kleiner Zwischenstand ... Music hört sich jetzt in Ordnung an,

Bezieht sich das jetzt auf die Microcontroller- oder die FPGA-Version?

[Mampf F. (mampf)]

Markus schrieb:
> Bezieht sich das jetzt auf die Microcontroller- oder die FPGA-Version?

Die FPGA-Version :)

Ah hmm, mist ... Mit der CPU vom FPGA64 Projekt läuft es einwandfrei 
(zumindest das eine Lied, hab noch kein anderes getestet). D.h. ich muss 
weiter Cores testen, bis ich einen finde, der funktioniert und der 
lizenztechnisch kein solcher Albtraum ist wie der von FPGA64 :)

Falls ich Wizball in Stereo zum Laufen bekomme, dann nehm ich es auf und 
lade es hoch^^

[Mampf F. (mampf)]

Zlorfix ... hab mir ein schönes Stereo-SID-File herausgesucht und jetzt 
ist die libsidplay zu alt, um es zu laden.

D.h. ich darf die libsidplayfp nochmal für den ARM kompilieren ...

Die Lib brauch ich, um den RAM und ROM Inhalt als quasi eine Art 
Memory-Image zu bauen, das ich dann in den FPGA lade ... Ohne 
libsidplay(fp) wäre das nahezu unmöglich selbst zu implementieren ... 
Krasser Scheiß, was die da alles in der Lib machen ... Installieren 
selber noch irgendwelche Treiber (mit Hardware-Initialisierung), 
relokieren C64-Code usw^^

[Mampf F. (mampf)]

Hier noch ein Stereo-SID (der zweite Kanal beginnt erst nach 30 
Sekunden!), abgespielt auf dem FPGA :)

Man hört noch ein leichtes Knacken öfters ... Mal kucken, was das wieder 
ist ;-)

*edit*: Ah, mir fällt ein ... Womöglich könnte man das FPGA64-Projekt 
doch nutzen, wenn man nicht den Code redistributed, sondern ein 
Patch-File anbietet, womit die Projekt-Files gepatcht werden können :)

Vielleicht mach ich das ... Glaube, das könnte ein ziemlicher Aufwand 
sein, bis alle SID-Files auf dem FPGA laufen - und soviel Motivation und 
Zeit hab ich nicht ;-)

edit2 *UND* ich hab herausgefunden, weshalb der t6502_rc-CPU-Core 
nicht vernünftig funktioniert hat.

Der hat eine Kleinigkeit vom echten 6502 nicht implementiert ... Wenn 
der VIC die CPU per BA-Signal unterbricht, dann schreibt dieser noch 
schnell Daten weg, bevor sie dann auf den VIC wartet, bis dieser 
wiederrum die CPU wieder frei gibt.

Das dauert 3 Taktzyklen, aber die t6502_rc-Implementierung hatte mit dem 
BA-Signal sofort die Arbeit eingestellt und das ging in die Hose.

Der (rettende) Trick war, das BA mit einem CPU_WR zu verodern, d.h. die 
CPU läuft weiter, solange sie schreibt und jetzt geht auch dieser Core 
richtig :)

[Mampf F. (mampf)]

Könnte ein Moderator bitte den Thread-Titel in "SID-Player ARM/FPGA?" 
ändern? :) Danke!

[Markus (Gast)]

Gratulation Mampf, Du bist ziemlich schnell.

Was mir beim MP3 auffällt: Die Musik klingt, als wenn Hall darin wäre.
Würde dieses SID-File noch auf einem echten C64 laufen mit 64K-Ram 
laufen?

[Mampf F. (mampf)]

Markus schrieb:
> Würde dieses SID-File noch auf einem echten C64 laufen mit 64K-Ram
> laufen?

Puh ehrlich gesagt, keine Ahnung! :D

Die Files haben noch einiges an Header-Zeugs vorne dran ... u.A. wohin 
sie ins RAM geladen werden, die I/O-Adresse des 2ten SIDs, ob PAL oder 
NTSC usw usf ...

Die werden von der Lib aber so aufbereitet, dass sie auf "echter" C64 
Hardware quasi laufen. Die Lib emuliert alles bis zu den Portpins des 
6510ers, mit denen die Speicherbereiche umgeschaltet werden.

Deshalb laufen die Files auch auf meinem FPGA-C64-Nachbau scheinbar 
problemlos.

Nachdem die lib den emulierten C64 initialisiert hat, dumpe ich die 
Speicherbereiche und lade sie in den FPGA und starte dann die CPU - und 
das funktioniert :)

Libsidplayfp kann mittlerweile auch PRG-files laden. Die wären dann 
direkt ohne irgendwas auf dem C64 abspielbar.

[Markus (Gast)]

>Markus schrieb:
>> Würde dieses SID-File noch auf einem echten C64 laufen mit 64K-Ram
>> laufen?
>Mampf
>Puh ehrlich gesagt, keine Ahnung! :D

Ich frage nur deshalb, weil mir der Klang so erscheint, als wenn die 
allerlei Tricks verwenden.
Normalerweise erzeugt man die Klänge des SID mit seinen internen 3 
Oszillatoren. Es gibt auch Programme, die einfach alle 20-50ms die 
Registerwerte für den SID mitschreiben. Damit kann man später den SID 
offline ( also ohne 6510 Emulation ) spielen, indem man einfach die 
Registerwerte mit der Rate an den SID schickt.
Aus der Akkustik Deines MP3-Files würde ich vermuten, dass sie die 
Oszillatoren des SID aber umgehen und den SID teilweise irgendwie als 
reinen DAC benutzen und mehr oder weniger Wav-Tables abspielen.
Dafür würde man aber mehr Speicher als die 64K benötigen, die der C64 
zur Verfügung hat.

Vielleicht gibt es hier ja jemand, der sich mit den Tricks für den SID 
auskennt.

[Mampf F. (mampf)]

Markus schrieb:
> Aus der Akkustik Deines MP3-Files würde ich vermuten, dass sie die
> Oszillatoren des SID aber umgehen und den SID teilweise irgendwie als
> reinen DAC benutzen und mehr oder weniger Wav-Tables abspielen.
> Dafür würde man aber mehr Speicher als die 64K benötigen, die der C64
> zur Verfügung hat.

Das täuscht :)

Ich hab Stereo-SID-Files in den Player geladen ... Der hat dann 3 
Stimmen pro links und rechts ... Die Implementierung selbst ist ein 
standard-SID, der nicht mehr kann.

Es gab einige MODs, mit denen man einen zweiten SID nachrüsten konnte.

Der C-One (für den ist FPGA64) ist standardmäßig mit 2 SID-Sockeln 
ausgestattet :)

Aber zu C64-Zeiten waren die Programmierer schon sehr trickreich :)

[Mampf F. (mampf)]

Das hier hat zB nur 7,3kB :)

[Jobst M. (jobstens-de)]

Michael H. schrieb:
> Leider nicht. Der Amiga hatte afaik einen Chip namens Paula welcher
> PCM-Samples per DMA abspielte.

Korrekt. 4 Audiospuren, 2 davon links, 2 rechts. 8 Bit, fs bis knapp 
über 50kHz, wenn ich mich recht erinnere.

> Aber falls du da tatsächlich noch eine Kiste mit SIDs im Keller hast
> dann sag Bescheid!! :D

Also ein paar habe ich noch ... ;-)
Von den 8580 könnte ich mir vorstellen, ein paar loszuwerden.
Sind unbenutzt.


H.Joachim S. schrieb:
> Ich schau morgen mal nach. Das waren auf jeden Fall DIL-ICs. Paula ja
> PLCC.

Nein, Paula ist DIL. Agnus ist PLCC.


Gruß
Jobst

[Markus (Gast)]

>Also ein paar habe ich noch ... ;-)

Gold in Chipform ....

[Jobst M. (jobstens-de)]

Cyblord -. schrieb:
> Was zum Geier ist SID?

Das Vieh aus Ice Age. Grundwissen.
;-)


Markus schrieb:
> Gold in Chipform ....

Also wieder zurück in's Bankschließfach ...


Gruß
Jobst

[Mampf F. (mampf)]

Jetzt muss ich mir mal Gedanken darüber machen, wie ich den SID-Player 
hardware-technisch bauen wollen würde :)

Gäbe es Interesse, das ganze Dingens tragbar mit kleinem Display zu 
haben?

Ist halt schon nerdiger Scheiß^^

Wahrscheinlich läuft sidplayfp sowiso auf Android problemlos ;-)

Also irgendwie nett der Kram, aber wofür sollte man ihn denn jetzt 
wirklich verwenden?

[Michael H. (dowjones)]

Mampf F. schrieb:
> Jetzt muss ich mir mal Gedanken darüber machen, wie ich den SID-Player
> hardware-technisch bauen wollen würde :)
>
> Gäbe es Interesse, das ganze Dingens tragbar mit kleinem Display zu
> haben?

Hi Mampf,
mal aus Neugierde: Hast Du Dein Projekt mittlerweile erfolgreich 
abschließen können? Und gibt es eine Dokumentation dazu, mit deren Hilfe 
man es nachbauen kann? :D
Ich selber wäre noch immer sowohl an einem tragbaren Dingsie als auch an 
einer 19"-Variante interessiert.

PS: Und falls Du daran gedacht auch das Apspielen von MODs zu 
implementieren wäre das der absolute Hammer!! =D

[Mampf F. (mampf)]

Michael H. schrieb:
> mal aus Neugierde: Hast Du Dein Projekt mittlerweile erfolgreich
> abschließen können? Und gibt es eine Dokumentation dazu, mit deren Hilfe
> man es nachbauen kann? :D

Nah, hatte instantan damit aufgehört und mein DIY-STM32-Board der 
ursprünglich geplanten Verwendung zugeführt xD

Ein dedizierter SID-Player wär zwar nett ... Aber für was? :)

Jedes Smartphone kann die Dinger abspielen, das Thema tragbar ist also 
schon erschlagen.

Allerdings hätte ich wirklich noch mein zusammengetragenes Zeugs auf 
irgendeiner Webseite zum Download anbieten sollen, damit die Arbeit 
nicht ganz umsonst war.

Evtl migriere ich noch die Software vom DIY-STM32-Board auf einen 
Maple-Mini. Den SID-File-Loader würde ich auf den PC auslagern und per 
USB über das Discovery die Daten ins Altera DE1 schaufeln. (oder den 
auch noch weglassen und RS232 mit einem USB-RS232-Dongel verwenden? ? )

Das wäre kein großer Aufwand,eventuell Interessierte bräuchten keine 
Custom-Hardware und es könnte an einem Tag erledigt sein.

Dann den ganzen kram ins Netz werfen und sich selbst überlassen, so zu 
sagen ;)

Werde ich im Hinterkopf behalten ...^^

[das Rad neu erfinden (Gast)]

http://www.staringlizard.com/2015/12/03/memwa-ii/

wer nicht bei null anfangen will.

[Michael H. (dowjones)]

Mampf F. schrieb:
> Nah, hatte instantan damit aufgehört und mein DIY-STM32-Board der
> ursprünglich geplanten Verwendung zugeführt xD

Hach, ein Jammer...

Mampf F. schrieb:
> Jedes Smartphone kann die Dinger abspielen, das Thema tragbar ist
> also schon erschlagen.
Jaaaaa, aber das ist halt nicht dasselbe. Ich persönlich möchte die 
Musik von damals halt nicht nur auf einem seelenlosen Smartphone hören 
sondern auch "fühlen"; von daher käme für mich nur eine C64-Emulation in 
Frage die einen realen SID ansteuert. Hatte gehofft ich könnte mich bei 
der Realisierung dessen z.T. bei deinem Projekt bedienen. 8)

> Allerdings hätte ich wirklich noch mein zusammengetragenes Zeugs auf
> irgendeiner Webseite zum Download anbieten sollen, damit die Arbeit
> nicht ganz umsonst war.
Ja, mach mal! Jedes bisschen hilft bestimmt schon irgendjemandem weiter. 
:)

das Rad neu erfinden schrieb:
> http://www.staringlizard.com/2015/12/03/memwa-ii/
>
> wer nicht bei null anfangen will.
Ach das Teil ist ja putzig! xD

[Ordner (Gast)]

Cyblord -. schrieb:
> Was zum Geier ist SID?

Ich glaube, diese Rückfrage, sagt alles über den selbsternannten "Lord 
des Cyberspace" aus. Wie abgehoben und verquert kann man im Kopf sein, 
dass man in 30 Jahren nicht einmal das Wort mitbekommen hat und auch 
nicht in der Lage war, es zu googlen. Ich bin sicher, das Wort SID ist 
auch heute noch den meisten normalen Computernutzern eher inhaltlich 
bekannt, als solche Begriffe wie DDR, COM, DAO, was sie täglich nutzen.

Mampf F. schrieb:
> Jedes Smartphone kann die Dinger abspielen, das Thema tragbar ist also
> schon erschlagen.

[Ordner (Gast)]

Mampf F. schrieb:
> Jedes Smartphone kann die Dinger abspielen, das Thema tragbar ist also
> schon erschlagen.

Die Frage ist nur wie es klingt. Nach echtem SID sicher nicht.

[Mampf F. (mampf)]

Nur mal so am Rande ...

Hab das damalige Projekt - mittlerweile ja über 1 Jahr her, auf einem 
Cyclone 10LP "recycled" :)

https://www.youtube.com/watch?v=yl28o-LobGM

Dummerweise hab ich immer noch keine GPL/MIT-Variante eines 6502/6510 
gefunden, der da funktioniert.

T65 hatte ich ausprobiert und der 6502_tc von OpenCores auch ... 
Letzterer ging zumindest auf dem Altera DE1 letzten Jahr (ist wohl ein 
Timing-Problem, weil der lief mit externem SRAM - das aktuelle Board hat 
nur BlockRAM).

Falls noch jemand Ideen hat ... :)

[Andreas R. (daybyter)]

Hast mal im f64 Lilith gefragt? Der hat doch auch nen 6510 geschrieben?

[Johnny B. (johnnyb)]

Mampf F. schrieb:
> Kennt jemand noch andere SID-Emulator-Projekte, die sich für eine
> ARM-Portierung eignen würden?

Fürs Raspberry Pi, welches ja ARM basiert ist, gibt es komplette C64 
Emulatoren (VICE). Der Vorteil ist noch, dass Du die originalen 
Applikationen vom C64 verwenden kannst.
https://github.com/retropie/retropie-setup/wiki/Commodore-64-VIC-20-PET

[Mampf F. (mampf)]

Johnny B. schrieb:
> Mampf F. schrieb:
>> Kennt jemand noch andere SID-Emulator-Projekte, die sich für eine
>> ARM-Portierung eignen würden?
>
> Fürs Raspberry Pi, welches ja ARM basiert ist, gibt es komplette C64
> Emulatoren (VICE). Der Vorteil ist noch, dass Du die originalen
> Applikationen vom C64 verwenden kannst.
> https://github.com/retropie/retropie-setup/wiki/Co...

Danke für den Tipp, aber um einen Emulator auf einem ARM ging es mir 
eigentlich nicht - mein Projekt spielt SID-Musik auf einem 
synthetisierten C64 im FPGA ab quasi.

Ich hatte allerdings den VIC der libsidplayfp (Sid-Player für Linux) 
nach VHDL portiert (Mini-VIC ohne Video). (Die Komponente sollte ich mal 
frei geben ... Ist eigentlich eine der wenigen Neuerungen die auf meine 
Arbeit zurück gehen ... Der Rest ist mehr oder weniger nur Glue-Logic - 
ah für libsidplayfp-angepasstes internes RAM ... Der Cyclone 10LP hat 
davon zu wenig und das gesamte ROM (nachdem libsidplayfp alles 
installiert hat) lässt sich auf weniger als 32Byte kürzen^^).

Libsidplayfp macht intern noch viele andere Dinge... Für SID-Musik 
abspielen braucht man im Prinzip weder Kernel noch Basic und möchte 
keine Benutzer-Interaktion ´ala load "$",8.

Es bereitet ROM und RAM quasi so vor (neue Reset-Vektoren, Basic-Trap, 
SID-File in den RAM - und installiert sogar einen SID-Player im RAM, der 
nach dem Reset direkt ausgeführt wird!), dass nach dem Start des 
C64-Cores direkt das SID-File abgespielt wird.

Geniale Library!

Ich glaub ich teste mal den ag_6502 ... Da muss ich aber bisserl was 
umbauen, weil der die Signale Phi1 und Phi2 selbst erzeugt.

[Christian F. (feuerwerk)]

Hi Mampf

Ich weiss nicht ob es dir hilft, aber wenn du eine freie 
6502-Implementierung suchst, kann ich dir meine anbieten, vielleicht 
funktioniert sie für deinen Einsatzzweck. Ja, ich weiss, ist nicht die 
schönste Implementierung, aber nachdem diverse Test-Roms erfolgreich 
darauf laufen gehe ich davon aus, dass meine Implementierung ein 
akkurates Timing besitzt. Einzige Einschränkung derzeit: Nur die 
offiziellen Opcodes und es gibt keinen Dezimal-Modus

https://github.com/Feuerwerk/fpgaNES

Die relevanten Dateien sind cpu.vhd, common.vhd sequencer.vhd

Viel Erfolg mit deinem Projekt
Christian

[Mampf F. (mampf)]

Christian F. schrieb:
> Ich weiss nicht ob es dir hilft, aber wenn du eine freie
> 6502-Implementierung suchst, kann ich dir meine anbieten, vielleicht
> funktioniert sie für deinen Einsatzzweck.

Wow, ein NES! ???

Wieso ist mir denn das entgangen! :)

Vielen Dank für den Link!

Deine CPU probier ich demnächst mal aus :)

[SIDO (Gast)]

Mampf F. schrieb:
> Danke für den Tipp, aber um einen Emulator auf einem ARM ging es mir
> eigentlich nicht - mein Projekt spielt SID-Musik auf einem
> synthetisierten C64 im FPGA ab quasi.

Ich habe es immer noch nicht voll kapiert. Läuft nun der C64 auf dem 
FPGA und darauf oder dem ARM eine Software die SID macht oder ist der 
SID in Hardware abgebildet?

Im Fall1 empfehle ich, Dich mal mit denen hier kurz zu schließen:
https://hackaday.com/2015/02/06/a-raspberry-pi-sid-player/
https://www.arduinolibraries.info/libraries/stereo-sid

Der trötet bei mir erfolgreich!

Im Fall2, kämen die hier in Betracht:

http://www.swinkels.tvtom.pl/swinsid/
http://www.96khz.org/htm/sidemulation2.htm
http://www.fpgasid.de/project-definition

[Marcus (Gast)]

>Der trötet bei mir erfolgreich!

Welcher jetzt?

[Marcus (Gast)]

Hier gibt es eine Kollektion von SID-Stücken:
https://www.youtube.com/watch?v=U9Racui9jJI
Die meisten um 1988. Wie wohl modernere Stücke klingen würden?

[Sepp (Gast)]

War der SID nicht teilweise analog auf dem DIE ? Ich hatte einen C64 an 
einer analog Glotze und es klang gut... R-Type zB. hatte da einen 
ohrgasmischen Level.

[Andreas R. (daybyter)]

Ja, der SID teilweise analog. Deshalb kann man ihn heute auch nicht mehr 
nachfertigen, weil es keine Fabriken für die damaligen 
Fertigungsverfahren mehr gibt... ;-(

[C. A. Rotwang (Gast)]

Andreas R. schrieb:
> Ja, der SID teilweise analog. Deshalb kann man ihn heute auch nicht mehr
> nachfertigen, weil es keine Fabriken für die damaligen
> Fertigungsverfahren mehr gibt... ;-(

Naja, dann muss es eben nach-analogisieren, sollte doch anhand der 
scopebilder möglich sein:

https://www.youtube.com/watch?v=-3pGP1a3JRw

[J. S. (engineer)]

C. A. Rotwang schrieb:
> Naja, dann muss es eben nach-analogisieren, sollte doch anhand der
> scopebilder möglich sein:

Ich denke nicht, dass ScopeBilder wirklich genau genug sind, den Klang 
nachzustellen. Sie können vlt Hinweise geben, wohin man denken muss. 
Wenn man das richtig machen möchte, ist da einiges zu tun. Beim SID 
wirkt u.a. auch die Versorgungsspannung und der analoge Ausgang. Vom 
Sound über den TCV-Modulator ganz zu schweigen.

[C. A. Rotwang (Gast)]

Jürgen S. schrieb:
> C. A. Rotwang schrieb:
>> Naja, dann muss es eben nach-analogisieren, sollte doch anhand der
>> scopebilder möglich sein:
>
> Ich denke nicht, dass ScopeBilder wirklich genau genug sind, den Klang
> nachzustellen.

Nja es soll ja nicht ein Lautsprecher im FPGA nachmoduliert werden 
sondern lediglich ein Mixed signal IC resp. das von ihm erzeugte 
elektrische Signal und wenn man einen signalgenerator baut der den 
selben y(t)-Verlauf fabriziert dann hat der E-Magnet im Lautsprecher 
auch keine andere Chance als die selben mechanischen Schwingungen zu 
fabrizieren.
Von Audio-Esotorik wie monokristalinen Kupfer und bei Vollmand 
gestreckte Kabel halte ich nix.
Was am Ausgangstreiber am FPGA hinsichtlich Lastverhalten anders ist, 
muss man halt mit einer NF-Stufe nachbilden. C64 Schaltpläne liegen 
beispielsweise dort: 
http://personalpages.tds.net/~rcarlsen/cbm/c64/SCHEMATICS/250469/252312.jpg
 ein 2SC1815 sollte heute noch kaufbar sein.

[J. S. (engineer)]

C. A. Rotwang schrieb:
> Nja es soll ja nicht ein Lautsprecher im FPGA nachmoduliert werden
> sondern lediglich ein Mixed signal IC resp. das von ihm erzeugte
> elektrische Signal und wenn man einen signalgenerator baut der den
> selben y(t)-Verlauf fabriziert dann hat der E-Magnet im Lautsprecher
> auch keine andere Chance als die selben mechanischen Schwingungen zu
> fabrizieren.

Schon klar, nur ist eben jener Mixed Signal chip für sich schon sehr 
stark mit Effekten behaftet, die über die rein mathematische 
SRDN-Synthese hinaus geht. Ich habe ja Original-Aufnahmen vom SID und im 
Vergleich dazu das Emulatoren (und anderem dem Meinen) und das 
unterscheidet sich deutlich.

[Andi (Gast)]

Wenn ich so ein SID-Tune höre, wie im Video 4 Beiträge früher, dann 
frage ich mich:
Kommt es wirklich drauf an, ob die Musik nun original schrecklich 
klingt, oder leicht anders schrecklich ;-)

[Marcus (Gast)]

>Kommt es wirklich drauf an, ob die Musik nun original schrecklich
>klingt, oder leicht anders schrecklich ;-

Na, so schlecht klingt das nun auch wieder nicht.
https://www.youtube.com/watch?v=-3pGP1a3JRw

Und Du musst bedenken: Es ist wirklich exorbitant, was mit den damals 
beschränkten Techniken erreicht werden konnte. Die niedrige 
Rechenleistung war nämlich kaum wirklich für die Sounderzeugung 
geeignet.

Aber klar, ein paar Jahrzehnte später ist man immer Besseres gewohnt und 
belächelt das Vergangene.

[C. A. Rotwang (Gast)]

Jürgen S. schrieb:
> C. A. Rotwang schrieb:
>> Nja es soll ja nicht ein Lautsprecher im FPGA nachmoduliert werden
>> sondern lediglich ein Mixed signal IC resp. das von ihm erzeugte
>> elektrische Signal und wenn man einen signalgenerator baut der den
>> selben y(t)-Verlauf fabriziert dann hat der E-Magnet im Lautsprecher
>> auch keine andere Chance als die selben mechanischen Schwingungen zu
>> fabrizieren.
>
> Schon klar, nur ist eben jener Mixed Signal chip für sich schon sehr
> stark mit Effekten behaftet, die über die rein mathematische
> SRDN-Synthese hinaus geht. Ich habe ja Original-Aufnahmen vom SID und im
> Vergleich dazu das Emulatoren (und anderem dem Meinen) und das
> unterscheidet sich deutlich.

Diese Unterschiede zwischen Originalsample und Emugebläse sollten aber 
deutlich im Oszilloscop oder Spectrumanalyser sichtbar sein. Das ist 
doch der Kernpunkt der Nebendiskussion, Zitat:
"Ich denke nicht, dass ScopeBilder wirklich genau genug sind, den Klang
nachzustellen."

Diese meinung teile ich nicht im geringsten, ich dachte die leidigen 
Wettbewerbe "Wer hört den Unterschied zwischen CD und Kasette" oder gar 
MP3 wie sie noch in den neunzigern gängig wären gehören, endgültig der 
Vergangenheit an.

Damit es gleich klingt, sollte man schon die selbe Endstufe benutzen, 
also aus dem C64 Schaltplan den Transistor raussuchen und dem Eigenbau 
Emulator dranstöpseln. Dazwischen macht sich sicherlich noch ein OPV 
o.ä. gut um das Last-Strom Verhalten aka Ausgangswiderstand des 
SID-Nachbaus an den Originalen anzupassen. Das machen sicherlich die 
wenigsten Nachbauer. Klar könnte man dessen Kennlinie auch in den 
Digitalbau einrechnen, aber das macht wohl auch keiner sondern begnügt 
sich mit Gefasel über verlorengangenen Herstellertechnologien.
Wem Auswirkungen von Schwankungen der Betriebsspannung wichtig sind, 
ermittelt diese eben (bspw. durch eine FT über eine Aufzeichnung vom 
Original-Chip) und stellt sie nach, beispielsweise über eine AM geringer 
Frequenz oder TP mit variabler fg oder oder.
Für den Bereich bis 12 kHz für den es für den SID geht, sollte das ein 
FPGA oder DSP locker schaffen, den mit heutigen FPGA's kann man 
Funksignale im MHz-Bereich (SDR) synthetisieren, ich glaube daher nicht 
daß dies für Audiosamples geringer Frequenz, Qantisierung und Länge 
nicht möglich sein sollte. Das Problem liegt eher in der "Mühe" sich das 
Wissen zu erarbeiten oder einfach ein bißchen mit dem Parametern zu 
spielen um einen SID-Nachäffer so zu tunen, das ein menschliches Ohr 
keinen Unterschied hört.

Hier mal "mein Lieblingsvideo" zur Signalanalyse ;-)
https://youtu.be/uhIEfxRLiPI?t=37

Und Persönlich lass ich mir lieber vom Amiga, also von PAULA statt SID, 
die Trommelfelle freiblasen:
https://youtu.be/xmEhC91k3MI?t=61
https://youtu.be/1N-iV7NHWJQ?t=37
Obwohl dieses Sample klingt, als ob da jemand vergessen hat, den 7kHz 
Analogfilter das A500 abzuschalten.

[J. S. (engineer)]

Also einmal bezog ich mich auf deine Beispiel mit den Scope-Bildern auf 
YT. Die sind definitiv nicht genau genug, um was en detail zu 
beurteilen. Des weiteren ist zu sagen, dass Scope generell oft nur 8 Bit 
aufweisen und darstellen, von daher ...

Es ist auch schwierig, anhand einer Amplitudenabbildung den Klang und 
den Unterschied zu ersehen und gedanklich in Änderungen von Algorithmen 
zu übertragen. Wenn überhaupt, kommt man da mit einem Spektrumanalyzer 
und den Ohren weiter.

Beides habe ich getan. Ich kenne die einschlägigen Emulationen und habe 
hier auch Audiotechnik im Studio, die es mir gestattet, mehr zu hören 
und zu sehen, als es der Durchschnittsanwender kann.

Von daher bleibe ich bei der Haltung, dass eine authentische Nachbildung 
des SID oder anderer mixed-Signal-Audio-Chips schwierig bis unmöglich 
ist, auch wenn die Technologie durch DSPS und FPGAs es theoretisch 
leicht zuließe.

Es ist ja nicht so, dass ich keine Erfahrung in der Emulation in 
Analogtechnik hätte :-)

Bei der Bemerkung:

> ich dachte die leidigen Wettbewerbe "Wer hört den Unterschied
> zwischen CD und Kasette" oder gar MP3 wie sie noch in den neunzigern
> gängig wären gehören, endgültig der Vergangenheit an.
sehe ich noch nicht den Bezug zum Thema, stelle aber auch hier meine 
Haltung entgegen, dass diejenigen mit intakten Ohren selbstredend 
Unterschiede von Kassetten, CD und mp3 hören, zumal sich sich technisch 
quantifizieren lassen. Dass einige infolge ihrer Hörgewohnheiten nichts 
mehr hören, weil ihr Gehör verarmt ist, ist inzwischen bewiesenes Fakt, 
da öfters Gegenstand von wissenschaftlichen Untersuchungen. Frequenzen, 
die ein Hirn nicht mehr angeboten bekommt, weil das Ohr sie nicht 
transportiert, kann es nach einer Weile auch dann nicht mehr hören, wenn 
derjenige ein Hörgerät bekommt. Das Gehirn verlernt das Hören! Dieselben 
Effekte, die dazu führen, dass das Gehirn sich verändernde Ohrgeräusche 
durch Blutströmung und Ohrwachstum ausblenden kann und Bässe wahrnehmen 
kann, die nur durch Oberwellen skizziert werden sind auch dafür 
verantwortlich, Raumgrößen und Tiefen abzuschätzen und es ist ein Fakt, 
dass der Einheitsbrei, der den Ohren heute zugeführt wird, zu einem 
verarmen und letztlicher Nicherkennbarkeit führen.

[J. S. (engineer)]

Christian F. schrieb:
> https://github.com/Feuerwerk/fpgaNES

Das schaut interessant aus! Kann der auch schwarze OP-Codes?

[Christian F. (feuerwerk)]

Schwarze Opcodes? Du meinst die illegalen Opcodes?
Nein, derzeit noch nicht, genau wie meiner Implementierung noch der 
Decimal-Mode fehlt. Beides brauche ich für einen NES nicht, da keines 
der offiziellen Spiele illegale Opcodes verwendet. Nintendo hat da 
meines Wissens damals drauf geachtet. Nichts desto trotz will ich aber 
die CPU nochmal redesignen, sauberer programmieren und im Zuge dessen 
auch die sinnvollen illegalen Opcodes mit aufnehmen.

[Thomas Kindler (Gast)]

Ich hab' auch einen SID für FPGA geschrieben:

  https://github.com/thomask77/verilog-sid-mos6581

Bei Bedarf kann ich auch noch mein SiD4AVR-Projekt rauskramen. Läuft 
inkl. Filter usw. auf 20 MHz ATmegas

[J. S. (engineer)]

Christian F. schrieb:
> Schwarze Opcodes? Du meinst die illegalen Opcodes?
Solche Sachen wie LAX und n-Byte NOP.

Thomas Kindler schrieb:
> Ich hab' auch einen SID für FPGA geschrieben:
Demosounds verfügbar?

[Analoger (Gast)]

Thomas Kindler schrieb:
> Bei Bedarf kann ich auch noch mein SiD4AVR-Projekt rauskramen
Hallo Thomas, ich wäre an dem Projekt interessiert. Wieviel Resourcen 
belegt der? Ich hätte Bedarf, für etwas Kompaktes. Der beste SID ist 
angeblich der resid_fp von Dag Lem, mit dem Verzerrer von Antti Lankila. 
Leider verschluckt der ziemlich Rechenleistung.

> Ich hab' auch einen SID für FPGA geschrieben:
> https://github.com/thomask77/verilog-sid-mos6581
Ich habe jetzt das Projekt von Andreas Beermann ins Auge gefasst, nur 
gibt es das noch nicht und wenn nur als fertigen Chip. Dein Projekt wäre 
mir schon symphatisch, allerdings ist es offenbar Verilog?

Das Projekt von Jürgen Schuhmacher läuft offenbar nur auf seiner 
speziellen Hardware.

C. A. Rotwang schrieb:
> Klar könnte man dessen Kennlinie auch in den
> Digitalbau einrechnen, aber das macht wohl auch keiner sondern begnügt
> sich mit Gefasel über verlorengangenen Herstellertechnologien.
Antti Lankila scheint das gemacht zu haben.

[Let the Muic Play (Gast)]

C. A. Rotwang schrieb:
> Und Persönlich lass ich mir lieber vom Amiga, also von PAULA statt SID,
> die Trommelfelle freiblasen:
Der war aber doch gar kein SoundChip sondern nur ein 8BIT-Wandler.

> Youtube-Video "Amiga Longplay  R-Type"
Nee Danke!

[Thomas Kindler (Gast)]

Analoger schrieb:
> Thomas Kindler schrieb:
>> Bei Bedarf kann ich auch noch mein SiD4AVR-Projekt rauskramen
> Hallo Thomas, ich wäre an dem Projekt interessiert.

Hier, bitte:

  https://gist.github.com/thomask77/9b87389fe6e69f733d525be96f2f96a0

Der Code ist im wesentlichen ein Port von TinySID (kb^farbrausch).

Phasenakku ist 16 statt 24 Bit. Nur ein 15-Bit LFSR als Rauschgenerator 
für alle 3 Kanäle. Auflösung 8 statt 12 Bit. Multimode-Filter ist 
ebenfalls ein wenig abgespeckt, klingt aber super!

> Wieviel Resourcen belegt der?

Auf einem ATmega168 @ 20 MHz und 31250 Hz Abtastrate ca. 90% CPU-Zeit.

Soundausgabe am einfachsten über PWM-Pin und RC-Tiefpass.

Die SID-Registerzugriffe hatte ich per UART von einem PC-SID-Player 
übertragen.

Wenn man auf 15625 Hz runter geht, ist sogar genug Zeit für 
6510-Emulation übrig. Allerdings nur mit Tricks - man braucht z.B. eine 
Virtual-Memory-Tabelle mit Copy-on-Write, weil der ATmega nur 16k 
Speicher hat. Viele Sid-Tunes schreiben aber nur auf die Zero-Page + 
einige wenige weitere 256-Byte-Seiten.

Kann ich bei Interesse ebenfalls raussuchen.

Mit AVR-Assembler kann man bestimmt noch was rausholen.


Jürgen S. schrieb:
>> Ich hab' auch einen SID für FPGA geschrieben:
> Demosounds verfügbar?

Die FPGA-Variante sollte praktisch identisch mit TinySID sein. D.h. 
knackiger, aber nicht unbedingt Originalgetreuer Sound.

Bei SiD4AVR ging's mir um die Machbarkeit, weil alle anderen AVR-SIDs 
eher nicht so toll waren (z.B. fehlten fast immer die Filter). Die 
FPGA-Variante war ein Lernprojekt, weil ich mal was mit Verilog machen 
wollte. Kein Anspruch auf 100% Emulation oder so.

Viele Grüße,
Thomas

[C. A. Rotwang (Gast)]

Let the Muic Play schrieb:
> C. A. Rotwang schrieb:
>> Und Persönlich lass ich mir lieber vom Amiga, also von PAULA statt SID,
>> die Trommelfelle freiblasen:
> Der war aber doch gar kein SoundChip sondern nur ein 8BIT-Wandler.

Klar ist das ein Soundchip, wie auch eine Wavetable-Soundcard bspw. 
Gravis Ultrasound wie eine AdLib-Sound-Blaster Soundcards sind, auch 
wenn die Tonerzeugung eine komplett andere ist.

Du meinst wahrscheinlich das der SID im Gegensatz zur PAULA ein 
(analoger) Synthesizer ist. Damit hast natürlich recht, und 
wahrscheinlich ist das das Problem bei der Emulation.
Da muss man schauen wie weit das konzept der wertdiskreten Zeitreihe mit 
nachgeschaltetenen Bandbreitenbegrenzenden Filter fester 
Grenzfreqquenzcharakteristik (AD-Antialaising(Glättungs)-filter) 
überhaupt trägt. Vielleicht wäre es ja sinnvoll die Audio-quellen im 
Frequenzbereich also als Spektrallinien zu geneieren und erst nach dem 
Mischen über eine inverse Fouriertransformation in den Zeitbereich zu 
wechseln? Oder wenn schon Zeitbereich dann mit hoher Auflösung (i.e. 16 
statt 8 bit)?

Ob es dann auch so klar klingt wie Orchester aus 16 sinus-genratoren?
https://www.youtube.com/watch?v=FpOM4Fs08kU&list=PLplgBDMGD07XTbgruf-OEaQf9Mk4KlQjL&index=72

[Thomas Kindler (Gast)]

C. A. Rotwang schrieb:
> Du meinst wahrscheinlich das der SID im Gegensatz zur PAULA ein
> (analoger) Synthesizer ist. Damit hast natürlich recht, und
> wahrscheinlich ist das das Problem bei der Emulation.

Bis auf Filter und DAC ist der SID ein (für die damalige Zeit) recht 
moderner, digitaler Synthesizer.

Dreieck/Sägezahn/Square werden mit 12 Bit Auflösung direkt aus einem 24 
Bit Phasenakku erzeugt, Noise per LFSR.

Nur bei gleichzeitiger Auswahl von mehreren Wellenformen gibt es auch im 
Digitalteil ein paar Quasi-Analoge Dreckeffekte durch ein billig 
designtes Wired-AND.

Siehe auch:

  http://sid.kubarth.com/articles/interview_bob_yannes.html

C. A. Rotwang schrieb:
> Da muss man schauen wie weit das konzept der wertdiskreten Zeitreihe mit
> nachgeschaltetenen Bandbreitenbegrenzenden Filter fester
> Grenzfreqquenzcharakteri[.....]

Das sind alles gelöste Probleme: Digitalteil ist durch Chipfotos bis auf 
Gatterebene bekannt, und der Filter wird von resid_fp exzellent 
nachgebildet.

Das ist halt eher was für'n PC oder Raspi, weil Rechenaufwand. Der 
einfache TinySID-Filter "klingt" auch sehr gut.

[Soul E. (Gast)]

Mit dem SwinSID gibt es eine ganz passable SID-Emulation auf Basis eines 
Atmel AVR. Das Ding kann man direkt in den Sockel eines C64 setzen.

[J. S. (engineer)]

Thomas Kindler schrieb:
> Die FPGA-Variante sollte praktisch identisch mit TinySID sein. D.h.
> knackiger, aber nicht unbedingt Originalgetreuer Sound.

Ich hätte gerne mal ein Beispiel gehört, vor allem wegen des Filters.

Analoger schrieb:
> Das Projekt von Jürgen Schuhmacher läuft offenbar nur auf seiner
> speziellen Hardware.

Nicht ganz, die abgebildete Hardware ist eigentlich der Analog-Ersatz 
für die DACs, von denen das erste PLD-System ja keine hatte. Die sind im 
FPGA natürlich emuliert, bzw. werden nicht gebraucht, um nur die 
Wellen/Kanäle mischen zu können. Das gilt auch für die Verzerrungen der 
urtümlichen Analogtechnik.

Der SID-FPGA entstand eigentlich dadurch, dass ich die 
"Orgelarchitektur" entsprechend auf 8 Bit/16 Bit erweitert habe. Meiner 
kann daher auch eine Wellenform mehr - einfach deshalb weil sie da war. 
Umgekehrt verwende ich auch nicht die Adressen, die der SID kennt. 
Deshalb hilft dir der FPGA so direkt nicht weiter. Man braucht auch die 
Ansteuerung davor.

Ich habe das später nicht mehr weiter ausgebaut, SID-Sound mache ich 
heute umgekehrt durch Degradation der Phasenvektoren und 
Amplitudenvektoren vor und nach den Synthesemodulen sowie durch 
Einstellen der Filter und Verzerrer. Der entspricht natürlich nicht dem, 
was weiter oben gelinkt wurde. Ist aber gebrauchsfähiger, weil die 
degradierten Sounds sehr dominant sind und man nicht alle Stimme zu hart 
braten darf ... jedenfalls nicht beim Trance.

Was ich gerne benutze ist das multiplexing/cattering, mit dem die 
Tonvervielfachung gemacht wurde, um Akkorde zu erzeugen. Das klingt 
gleich irgendwie nach C64 :-)

Als Beispiel das Hauptmotiv aus "Thunderstorm" mit SID-Emu-Stimmen aus 
der Pyra2 auf einem Cyclone III-System von 2008:
http://www.96khz.org/htm/polyphonicsynthesizercyclone3platform.htm

Das Ding war zum damaligen Zeitpunkt auch schon 10 Jahre alt und im 
Original mit einer AWE64 / EMU Audity gespielt, mit echtem Donnerhall 
aus Samples - konnte man ja als SoundFont laden.

SID ist aus nostalgischen Gründen eine tolle Sache aber so richtig ging 
die Post damals mit den EMU-Chips und Wavetables ab.

[Thomas Kindler (Gast)]

Jürgen S. schrieb:
> Thomas Kindler schrieb:
>> Die FPGA-Variante sollte praktisch identisch mit TinySID sein. D.h.
>> knackiger, aber nicht unbedingt Originalgetreuer Sound.
>
> Ich hätte gerne mal ein Beispiel gehört, vor allem wegen des Filters.

http://freshmeat.sourceforge.net/projects/tinysid

[6502 (Gast)]

SID-Pinkompatibel auf ARM Basis:

http://dzi.n.cz/8bit/armsid/index_en.php

[J. S. (engineer)]

Thomas Kindler schrieb:
> http://freshmeat.sourceforge.net/projects/tinysid
HM, also ich finde da leider keine Sounds. Die Links auf den Code und 
der Webseite gehen auch irgendwie ins Leere (?)
Ist aber nicht so wichtig.

[Mar.co (Gast)]

Jürgen S. schrieb:
> SID ist aus nostalgischen Gründen eine tolle Sache aber so richtig ging
> die Post damals mit den EMU-Chips und Wavetables ab.
Alles richtig aber ein Vergleich mit Produkten, die 20 Jahre auseinander 
liegen :-) und uhne einen SID hätte es vielleicht andere Synthesizer gar 
nicht gegeben.

Thomas Kindler schrieb:
> Das sind alles gelöste Probleme: Digitalteil ist durch Chipfotos bis auf
> Gatterebene bekannt, und der Filter wird von resid_fp exzellent
> nachgebildet.
Na ob man aus einem Chipfoto das Verhalten der Bauelemente 
rekonstruieren kann, wage ich doch zu bezweiffeln. Kann ich nicht 
einschätzen.

[S. R. (svenska)]

Mar.co schrieb:
> Na ob man aus einem Chipfoto das Verhalten der Bauelemente
> rekonstruieren kann, wage ich doch zu bezweiffeln.

Ist möglich. So wurden u.a. die Mifare Classic-Karten analysiert.
Die ganze Rechentechnik des Ostblocks basierte darauf...

Im Übrigen gibt es einen Unterschied zwischen "Chipfotos" und "einem 
Chipfoto". Nämlich zumindest deren Anzahl. :-)

[C. A. Rotwang (Gast)]

S. R. schrieb:
>> Na ob man aus einem Chipfoto das Verhalten der Bauelemente
>> rekonstruieren kann, wage ich doch zu bezweiffeln.
> Die ganze Rechentechnik des Ostblocks basierte darauf...
Abschleifen und die Foto-Masken rekonstruieren führt aber 
erfahrungsgemäß nicht zu völlig identischen Verhalten, da es einige 
Unterschiede zwischen U880 und Z80 gibt.
http://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=11288

Kann natürlich sein, das der Tester am Schluss den Unterschied macht, 
wenn man dessen Programm nicht raubkopiert, selektiert man u.U. die 
falschen als einwandfrei ...

Oder nicht alle Verfahrensschritte lassen sich durch Rekonstruktion der 
Photo-Masken nachäffen wie Epataxie und selektive Ionen-Implantierung.

Und irgendwann werden die Strukturen zu klein als dass man sie noch mit 
einem Lichtmikroskop abfotografieren kann sondern nur noch mit dem 
Rasterkraftmikroskop abrastern.

Wenn ich mich recht erinnere, hat sich die DDR wohl noch an einem i386 
Nachbau nach dieser Methode versucht und ist ziemlich vollständig daran 
gescheitert, da es nicht gelang die Fehler die beim "Abfotografieren" 
entstanden Schritt um Schritt zu eliminieren, weil man daran scheiterte 
vom beobachteten Fehlverhalten an den CPU- Pins auf die Fehlkopierte 
Stelle in den Masken zu schliessen ... Oder vereinzelte  Hot spots 
sorgten für verkürzte Lebensdauer ...
Schliesslich lag der Transistorcount beim i386 bei 275 000, beim Z-80 
dagegen bei 8500 -> viel weniger Möglichkeiten, was "falsch" 
abzukopieren. Beim SID werden 2500 Transistoren geschätzt, also knapp 
halbsoviel wie die zugehörige CPU, wobei m.E. diese Schätzung für den 
SID zu hoch ist.

[Thomas Kindler (Gast)]

Mar.co schrieb:
> Na ob man aus einem Chipfoto das Verhalten der Bauelemente
> rekonstruieren kann, wage ich doch zu bezweiffeln. Kann ich nicht
> einschätzen.

Siehe auch:

  http://www.visual6502.org/
  http://www.visual6502.org/JSSim/index.html

Simulation auf Gatterebene, aus Chip-Fotos erstellt. Läuft direkt im 
Browser, mit x/z rein/rauszoombar.

Weitere Beispiele:

  http://www.righto.com/search/label/reverse-engineering

Man kann auch Firmen dafür anheuern, z.B.:

  https://zeptobars.com

[S. R. (svenska)]

C. A. Rotwang schrieb:
>>> Na ob man aus einem Chipfoto das Verhalten der Bauelemente
>>> rekonstruieren kann, wage ich doch zu bezweiffeln.
>> Die ganze Rechentechnik des Ostblocks basierte darauf...
> Abschleifen und die Foto-Masken rekonstruieren führt aber
> erfahrungsgemäß nicht zu völlig identischen Verhalten, da es einige
> Unterschiede zwischen U880 und Z80 gibt.

Die DDR hatte andere Fertigungstechniken und -maschinen, deswegen 
handelt es sich nur sehr selten um exakte Kopien. Außerdem wurden auch 
andere Quellen für die Entwicklung benutzt - im Fall des Z80 zum 
Beispiel dessen Datenblatt. :-)

Ich dachte allerdings mehr an die russischen i8080-Klone und sonstige 
Chips.

[C. A. Rotwang (Gast)]

S. R. schrieb:
> Ich dachte allerdings mehr an die russischen i8080-Klone und sonstige
> Chips.

Hm, ich bin mir nicht sicher, ob die Ostblock-Rechentechnik mehr von den 
Clones aus der Sowjetunion oder von denen aus der DDR bestimmt wurde.

Die paranoiden sowjetischen Bürokraten behielten ihre (Top-)Chips lieber 
fürs eigene Militär geheim resp. exklusiv.
Daher nehme ich an, das der Ostblock eher auf  Z80 -Clones U880 (der 
aber selber ein i8080 Clone sein soll ?!) lief, als mit den russischen. 
Aber das ist nur ne persönliche Vermutung.

Dort kann man einiges zum Verhältniss DDR und SU Chipentwicklung finden: 
http://www.hait.tu-dresden.de/dok/bst/Heft_29_Barkleit.pdf

[S. R. (svenska)]

Hmm. Der U880 ist der einzige Z80-Klon aus dem Ostblock (und ein echter 
Z80, mit weniger Bugs als das Original), sonst gab es nur den älteren 
KR580VM80A. Beide wurden jedenfalls in (Hobby-)Computern verwendet.

Danke für den Link!

[J. S. (engineer)]

Thomas Kindler schrieb:
> Simulation auf Gatterebene, aus Chip-Fotos erstellt. Läuft direkt im
> Browser, mit x/z rein/rauszoombar.
Das ist ja nett! Cool!

Allerdings gibt es in Sachen Technologie ja einiges an Randbedingungen, 
die bei gleicher Geometrie zu völlig anderen Daten führen. An das Uni 
haben wir das mit Gauss simuliert und 3D-Modelle aus den Strukturen 
extrahiert. Da sind geringe Nuancen schon ausschlaggebend.

[Audio Freak (Gast)]

Mar.co schrieb:
> Jürgen S. schrieb:
>> SID ist aus nostalgischen Gründen eine tolle Sache aber so richtig ging
>> die Post damals mit den EMU-Chips und Wavetables ab.
> Alles richtig aber ein Vergleich mit Produkten, die 20 Jahre auseinander
> liegen :-) und ohne einen SID hätte es vielleicht andere Synthesizer gar
> nicht gegeben.

Soweit ich mal gehört habe, hat der Entwickler des SID später auch bei 
der Creative Soundblaster Entwicklung mitgewirkt. Die lagen auch nur gut 
10 Jahre auseinander.

[Simon R. (Gast)]

C. A. Rotwang schrieb:
> Dort kann man einiges zum Verhältniss DDR und SU Chipentwicklung finden:
Sehr interessant! Heute arbeiten die wahrscheinlich mit den Chinesen 
zusammen.