Modifications of my Atari 520 STm

Here comes the english tranlation of the article i wrote in german yesterday.

I spent a lot of time in the last few days on upgrading my ST 520, and wanted to share that. But it was too long for a simple forum post, so i decided to write an article about it here.

Step 1: Preparation 

In this picture, you can see the CPU in the middle. I have soldered a socket right on top of it. This is needed in order to add an IDE Adapter later. To the right you can see the IDE-CF-Adapter that i will connect to that. I just glued that on top of the ROM socket, and wired the 5V supply to a nearby spot. This means the ROM port will be blocked, since normal cartridges will no longer fit. But i don't have any cartridge anyways, and as far as i know, they were not used very often. Also, this is completely reversible. Above the CPU, where the Floppy controller used to be, i soldered in a socket. I didn't have the right one, so i just cut a 40-pin socket shorter. In between that socket and the CPU, there is one capacitor i had to change for a smaller type, because the original one was too tall to fit the HD-Module. You can also spot the single wire from the ACSI port, that is the needed IRQ signal for the IDE controller.

Step 2: HD-Floppies

The STm 520 has no internal Floppy drive, that means there is some extra effort required to be able to use HD (aka 1.44 MB) disks. Somehow, the HD-Detect signal must get from the drives to the HD-Module. If you are willing to limit yourself to a single drive, you can use the DS1 wire for that. But i wanted to have two drives. Luckily, there is a way to do that. Atari has used two ground pins on the Floppy connector. In this picture, you can see the floppy port from the inside of the ST. On the right side, one of the two ground pins is visible, and i just cut that and bent it up. Soldered onto that is the wire that gets the HD-signal to the floppy controller. That means that an original Atari Diskstation will no longer work on this port, because the floppy controller would always run in HD-Mode. But that is a compromise i was willing to take.

Here, i already plugged in the HD-Module with the Controller chip on top. This sits very close to the CPU, and i had to file off a bit of the PCB to make it fit. Space is very limited here, and there is no way the metal shield will still fit in here. But that is not required for the ST to work, and it is totally reversible. And my main concern was to keep the ST unmodified on the outside. Aside from a bit of yellowing on some keys, this ST is in perfect condition, including the original packaging and all. Therefore, i want it to look really original as well. But for several reasons, the HD-Mod was important to me. Firstly, the space on a 720 kB disk is very limited. With RAMTOS loader a TOS image, IDE- and ANSI-drivers, the disk is already almost full. Secondly, HD disks are not only twice as big, but also twice as fast, so the boot time is cut in half. And last but not least, those DD-disks are really hard to get these days, while HD disks are still available in many stores.

Step 3: IDE-Adaptor

The IDE adaptor i use here is a handwired one, based on the known c't design. The two empty sockets are for 74HCT245 bus drivers, but i never got those to work. That is not a problem in this case, because i will only use a very short cable. The HD-Module is now completely covered under the IDE adaptor, just the cable for the HD signal is visible on the left. The module i used here is very versatile, so it has more wires than i actually need. Since i put a bit more effort in the modification of the drives themselfes, one single wire would be sufficient here. But more on that later. As you can also see, i mounted a small fan to the top cover. Not permanently, i just used a bit of glue-gum or whatever it is actually called. That can be removed without residue if needed. It is obvious in this picture that not only the floppy controller, but also the CPU are completely covered now, and that makes passive cooling impossible. While testing, i encountered read and write errors on disks, but they completely dissapeared with this additional forced airflow.

A little creativity was required for routing the IDE cable. Directly next to the CF socket, there is one of the screw holes that hold the machine together. If you enlarge the picture, you can see that i also had to modify that a little bit. But since that is hidden inside the case, and has no influence on the function, i convinced myself to do it. This finishes the modifications inside the ST, all thats left to do is modify the actual drives themselfes.

Step 4: Floppydrives

Most people use the very simple method of just running a wire from the HD sensor inside the drive to pin 2 on the ribbon connector. While this works, it has some downsides to it. Because if done that way, the drive always pulls the HD signal low, as long as there is a HD disk in the drive. This means the HD-Module has to know when the drive is actually active, in order to not permanently overclock the floppy controller. It also makes it impossible to use DD and HD disks on the same cable. On top of that, Atari used a diffrent way to detect a disk change. In Ataris, the WP (write protect) line is pulled low not only when a write protected disk is in the drive, but also when the drive is empty.

Lucky for me, someone already thought this through and developed a circuit for that. It just needs a single 74LS03 chip, that is a NAND chip with 4 gates and open collector outputs. Only 3 of the 4 NAND gates are used here. One of them is free, in case one of the signals inside the drive needs to be inverted. I just glued the 74LS03 to a free spot on the PCB, and used strands of ribbon cable to wire it all up. It looks kind of messy here, bit this drive, a SONY MPF920, has a full metal cover on the bottom side. The chip fits under that just perfectly, and the wires will be protected while handling and mounting the drive. That is why i did not fix the cables any more. Many drives are open on the bottom, and in this case, i would have glued the cables onto the PCB as well. This little circuit generates the HD signal and the Atari-style disk change detection, all in one. The schematic for that, and another drive model as an example can be found here: http://atari.8bitchip.info/flomodam.html

Thats basically it, all thats still needed is a cable and case for the external disk drives. One could modify  the original Atari Diskstation for that, by cutting the second ground pin there as well, and connecting it to pin 2 on the disk drive. With this modification, the drive will only output a HD signal when it is beeing accessed by the computer, so that the floppy controller is only overclocked when neccessary.

Atari 520STm Modifikationen

In den letzten Tagen hab ich ziemlich viel an meinem Atari 520 herumgebastelt, und möchte das ganze auch gerne teilen. Aber es ist ein bisschen zu umfangreich für einen Forumspost, deshalb schreibe ich hier einen Artikel darüber.

Schritt 1: Vorbereitung

Auf diesem Bild sieht man in der
Mitte die CPU, die ich mit einem passenden Sockel "gekrönt" habe. Das ist nötig, um einen IDE-Adapter einbauen zu können. Am linken Rand ist der dazugehörige IDE->CF Adapter. Diesen habe ich einfach mit Uhu auf den ROM-Cartridge Steckplatz geklebt. Das bedeutet zwar das eine normale Cratridge jetzt nichtmehr hinein passt, aber die werden eher selten benutzt, ich selbst habe nicht eine einzige, und es ist komplett rückbaubar. Obderhalb der CPU, wo eigentlich der Floppycontroller sitzt, habe ich einen Sockel eingelötet. Zwischen diesem und der CPU musste ich noch den Elko durch einen kleineren ersetzen, sonst würde das HD-Floppy-Modul nicht passen. Neben dem Floppy-Sockel hab ich die 5V für die CF-Karte abgezapft. Außerdem sieht man noch die einzelne Leitung die ich vom ACSI-Port für den IDE-Adapter verlegt habe.

Schritt 2: HD-Floppies


Der ST 520 hat kein internes Diskettenlaufwerk, daher ist ein bisschen zusätzlicher Aufwand nötig um HD-Disketten benutzen zu können. Dafür muß irgendwie das HD-Detect Signal von den Laufwerken zum HD-Modul geführt werden. Wenn man bereit ist, sich auf ein einzelnes Laufwerk zu beschränken, dann kann man dafür die DS1-Leitung nehmen. Ich wollte aber auf jeden Fall zwei Laufwerke haben. Zum Glück gibt es einen Ausweg, denn Atari hat auf diesem Anschluß zwei Masseleitungen verbaut. Hier sieht man die Floppy-Buchse des ST von der Rückseite. Auf der rechten Seite davon ist einer der beiden Massepins sichtbar, und diesen habe ich am unteren Ende abgezwickt und hoch gebogen. Daran angelötet ist die Leitung die das HD-Signal zum Floppycontroller führt. Das bedeutet, das eine original Atari Diskstation nichtmehr an dieser Buchse funktioniert, weil der Controller damit permanent im HD-Modus arbeiten würde. Das ist aber ein Kompromiss, den ich bereit bin einzugehen.

Hier ist schon das HD-Modul mit dem Controller gesteckt. Dieses sitzt extrem dicht neben der CPU, und ich musste die Platine tatsächlich ein bisschen zurecht feilen, damit es so passt. Die Platzverhältnisse sind hier sehr beengt, und mit allen Modifikationen passt auf jeden Fall das original Abschirmblech nichtmehr. Aber auch das ist voll umkehrbar. Und das war mir wichtig, auch das der ST von außen unverbastelt bleibt. Bis auf ein bisschen Gilb ist dieser ST in einem fast perfekten Zustand, ich hab auch noch die Originalverpackung und alles. Da soll er auch möglichst original aussehen. Die HD-Floppy Modifikation war mir aber sehr wichtig, aus mehreren Gründen. Zum einen ist natürlich der Platz auf einer DD-Diskette sehr begrenzt. Mit RAMTOS Loader, einem TOS-Image, Festplatten- und ANSI-Treiber sind die 720 kB schon fast ausgeschöpft. Aber HD-Disketten sind nicht nur doppelt so groß, sondern auch doppelt so schnell. Das beschleunigt den Bootvorgang ganz erheblich. Dazu kommt noch, das DD-Disketten inzwischen sehr selten geworden sind, HD-Disketten sind aber noch neu im Laden zu bekommen.

Schritt 3: IDE-Adapter

Der IDE-Adapter den ich hier einbaue ist eine Handarbeit nach der bekannten Schaltung aus der c't. Die beiden leeren Sockel sind für 74HCT245 Bustreiber vorgesehen. Aber die habe ich nicht zum funktionieren gebracht. Da hier aber nur ein relativ kurzes Kabel zum Einsatz kommt, ist das kein Problem. Das HD-Floppy-Modul ist jetzt komplett unter dem IDE-Adapter unsichtbar. Man sieht nur links das Kabel herauskommen das das HD-Signal führt. Das HD-Modul ist sehr vielseitig, daher hat es mehr Leitungen als hier nötig sind. Ich habe beim Umbau der Floppylaufwerke etwas mehr Aufwand betrieben, daher würde eine einzige Leitung für das HD-Signal eigentlich ausreichen. Doch dazu später mehr. Was man hier auch sehen kann, ich hab im Gehäusedeckel einen kleinen Lüfter montiert. Nicht fest, sondern nur mit Klebegummi, das sich rückstandsfrei wieder entfernen lässt. Auf diesem Bild sieht man sehr deutlich, das sowohl die CPU als auch der Floppycontroller komplett verdeckt sind, und das macht eine passive Kühlung praktisch unmöglich. Bei Tests habe ich immer wieder Lese- oder Schreibfehler auf Disketten gehabt, die erst mit der zusätzlichen "Zwangsbeatmung" verschwunden sind.

Ein bisschen Kreativität ist dann noch nötig beim Verlegen des IDE-Kabels. Direkt neben dem CF-Adapter befindet sich nämlich einer der Befestigungspunkte mit denen der Rechner zusammen geschraubt wird. Wenn man das Bild vergrößert, kann man erkennen das ich auch diesen ein bisschen modifizieren musste. Da das aber im Gehäuseinneren ist, und auf die normale Funktion keinen Einfluss hat, konnte ich mich dazu durchringen.

Damit ist im Atari ST eigentlich alles erledigt, bleibt nurnoch die Modifikation der Floppylaufwerke selbst.

Schritt 4: Laufwerke

Die meisten greifen hier auf eine sehr einfache Möglichkeit zurück, einfach den HD-Sensor im Laufwerk mit Pin2 am Kabelanschluß zu verbinden. Das funktioniert zwar, hat aber einige Einschränkungen. Denn das Laufwerk zieht den HD-Pin dann immer auf Low, sobald eine HD-Disk im Laufwerk liegt. Daher muss dann die HD-Platine wissen, wann ein Laufwerk angesprochen wird, um den Controller-IC nicht permanent mit der doppelten Taktrate zu betreiben. Außerdem unterstützen normale PC-Floppies nicht die Methode, die Atari gewählt hat, um einen Diskettenwechsel zu erkennen. Bei Atari wird dazu die Write-Protect Leitung nicht nur dann auf Masse gezogen, wenn eine schreibgeschützte Diskette im Laufwerk liegt, sondern auch dann, wenn das Laufwerk leer ist.

Zum Glück hat sich dazu schonmal jemand gründlich Gedanken gemacht und eine entsprechende Schaltung entwickelt. Benötigt wird dazu nur ein einziger 74LS03 Chip, ein Open Collector NAND Baustein mit vier Gattern. Von denen werden nur drei gebraucht, eins ist frei als Inverter, für den Fall das der HD-Sensor im Laufwerk nicht Low- sondern High-Aktiv ist.
Ich hab den 74LS03 auf einer freien Stelle der Platine mit ein bisschen Uhu festgeklebt, und die nötigen Verbindungen mit einzelnen Drähten eines Flachbandkabels gemacht. Das sieht hier ziemlich Chaotisch aus, aber bei diesem Laufwerk, einem Sony MPF920, ist die Unterseite komplett mit einer Metallabdeckung verschlossen. Da passt der Chip gerade so drunter, und die Leitungen laufen nicht Gefahr beim Montieren des Laufwerks irgendwo hängen zu bleiben. Daher hab ich hier auf zusätzliche Sicherung verzichtet. Viele Laufwerke sind auf der Unterseite offen, da würde ich dringend dazu raten die Leitungen mit etwas Kleber auf der Platine zu sichern. Diese kleine Schaltung erledigt sowohl die HD-Erkennung, als auch das Diskwechsel-Signal auf Atari-Art. Das Schaltbild dazu, und ein Beispiel mit einem anderen Laufwerk (Chinon FG-357) findet sich hier: http://atari.8bitchip.info/flomodam.html

Das wars eigentlich schon, fehlt nurnoch das externe Kabel vom Atari zum Laufwerk, sowie ein Laufwerksgehäuse. Man kann dafür eine original Atari Diskstation umbauen, natürlich muss dann auch dort der doppelte Massepin abgetrennt und mit dem HD-Signal belegt werden. Das Laufwerk gibt nach diesem Umbau wirklich nur dann ein HD-Signal aus, wenn es vom Rechner aus angesprochen wird, dadurch wird der Floppycontroller nur dann übertaktet, wenn es auch wirklich nötig ist. 

PC Upgrades 2

Ich war also soweit das der Rechner wieder halbwegs stabil lief.
Mit einem eingeklebten Zusatzlüfter, notddürftig befestigtem Radiator, ständig am Temperaturlimit, aber es lief. Aber es war klar, ich brauche auf jeden Fall ein anderes Gehäuse, in das ich mehr Lüfter einbauen kann und auch den Radiator ordentlich befestigen.
Außerdem hat mich die Optik des Rechners schon lange gestört. Nicht das es technisch gesehen eine Rolle spielt, aber seit ich ein Gehäuse mit Seitenfenster habe, sehe ich es halt dauernd. Und ich hatte mir schon lange ein moderneres Gehäuse gewünscht. Ich wollte eine Abdeckung unter der das Netzteil verschwindet, Platz um alle Kabel versteckt zu verlegen, versteckte Montageplätze für Festplatten, viele Einbaumöglichkeiten für Lüfter und Radiatoren, Staubfilter, all die Sachen die heute schon fast standard sind, die mein Gehäuse aber nicht hatte.

Also stand als nächstes nicht das neue Mainboard auf dem Plan, sondern ein neues Gehäuse. Und wo ich schon dabei war, sollten auch gleich ein paar PWM-Lüfter dazu kommen.
Bei der für mich typischen gründlichen Suche fand ich ein echtes Schnäppchen: Das AeroCool 300 FAW Edition. Hat alle Features die ich mir gewünscht hatte, plus ein wirklich hübsches Seitenteil aus Acrylglas. Und das für gerade mal 40€. Dazu wollte ich dann zuerst ein paar rote LED-Lüfter, die waren aber nicht direkt lieferbar. Daher hab ich mich dann für 3 Scythe GlideStream Lüfter entschieden. Die können wirklich sehr viel Luft schaufeln, über 140 m³/h, lassen sich aber auch auf 300 Umdrehungen runter regeln wo sie dann praktisch unhörbar sind. Bis das Gehäuse wirklich angekommen war, hatte ich eigentlich vor die Schutzfolie auf dem Fenster zu lassen so lange wie möglich, aber wie man hier sehr gut sehen kann war das keine echte Option. Aber kein großes Problem. Also zuerst mal meinen kompletten Rechner in sämtliche Einzelteile zerlegt, was ich seit über einem Jahr nicht mehr gemacht hatte.

Nach einer gefühlten Ewigkeit hatte ich dann alles zerlegt. Das DVD-Laufwerk und ein paar Steckkarten kommen in das neue Gehäuse nicht mit rein, obwohl es möglich wäre. Aber ich will es diesmal ordentlich und sauber machen. Die noch nicht erwähnten Komponenten sind ein ASRock 980DE3/U3S3 rev 2 Mainboard, eine Gigabyte GeForce GTX 660 Ti, 8 GB RAM von mushkin, ein Thermaltake Hamburg 530W Netzteil und eine Toshiba 1TB Festplatte.
Das alles muß jetzt nurnoch in das neue Gehäuse passen, und zwar halbwegs ordentlich.

Anstatt den ganzen Prozess so zu schildern wie ich ihn durchlaufen habe, werde ich es so beschreiben wie man es idealerweise machen sollte. Als aller erstes sollte man die Festplatte montieren, weil man sonst nicht mehr an die Schraublöcher kommt. Man kann die Festplatte auch so montieren mit den mitgelieferten Rändelschrauben, aber ich mag es wenn Sachen richtig festgeschraubt sind.

Danach kommt das Netzteil, hier ist nichts besonderes zu beachten. Es ist aber wichtig das Netzteil vor dem Mainboard einzubauen, es sei denn man verwendet Verlängerungskabel für den 8-pin EPS 12V Anschluß. Die Öffnung an der linken oberen Ecke wird nämlich vom Mainboard verdeckt, so daß man das Kabel vorher reinlegen muß. Kein großes Problem, wenn man es weiß. Danach beim Einbau des Mainboards sollte man (falls nötig) die Backplate zusammen mit dem Board einbauen, weil die Öffnung auf der Rückseite die Schraublöcher teilweise verdeckt, zumindest bei diesem Board. Die Montage des Kühlblocks ist in diesem Fall kein Problem, nur 4 Schrauben von Hand anziehen und fertig. Hier hab ich dann auch gleich noch die Audio-, USB- und SATA-Kabel am unteren Rand des Mainboards montiert. Was man hier auch sehen kann ist der Radiator, den ich aber später an anderer Stelle untergebracht habe. An dieser Stelle ist es eigentlich schon fast erledigt. Nurnoch die Grafikkarte einbauen, PCIe-Stromkabel einstecken und die Kabel sauber verlegen.

Nach einigem probieren hab ich in der Front zwei der Scythe-Lüfter eigebaut, und darüber den Radiator der Cooler Master Seidon 120V mit dem dazu gehörenden Lüfter. Dadurch wird die CPU direkt mit frischer Luft von aussen gekühlt, anstatt die Abwärme der Grafikkarte dafür zu benutzen. Der dritte Scythe Lüfter sitzt oben, ebenfalls als Eingangslüfter. Einen Ausgangslüfter habe ich im Moment garnicht, was aber kein Problem darstellt. Die Rückseite des Gehäuses ist sehr offen, die Luft kann also problemlos aus dem Gehäuse. Und ich wollte die Staubfilter wirklich gut benutzen, damit mein PC endlich mal sauber bleibt.
Und bisher funktioniert es perfekt. Die Temperaturen sind gut, der Rechner ist dank SpeedFan flüsterleise. Selbst unter Vollast ist er jetzt deutlich leiser als vorher im Leerlauf. Und ich habe nach 2 Wochen noch immer keinen Sichtbaren Staub im Gehäuse. Jetzt warte ich sehnlich auf das neue Mainboard, aber das wird noch eine Weile dauern. Bis dahin hab ich aber ein ansehnliches System auf dem Schreibtisch stehen. Und obwohl es noch bei weitem nicht perfekt ist, ertappe ich mich immer wieder dabei das ich ein paar Minuten nur meinen PC anschaue und mich daran freue wie ordentlich er jetzt aussieht. Und er wird noch viel besser wenn er fertig ist.

PC Upgrades

Nach langer Zeit hatte ich in den letzten 2 Monaten endlich mal wieder etwas Geld für meinen PC. Und als erstes wollte ich eine schnellere CPU. Der FX-4300 hat mir jetzt eineinhalb Jahre gute Dienste geleistet, aber ein Quadcore war mir einfach zu wenig.
Ein Upgrade auf ein Ryzen System war mir aber einerseits zu teuer, andererseits ist es eine ganz neue Platformund noch nicht richtig ausgereift. Und wie immer bei einer ganz neuen Generation, bezahlt man natürlich einen Aufpreis für die Entwicklung mit. Also obwohl die Ryzen CPUs sehr gut und eigentlich auch preiswert sind, habe ich mich entschieden nochmal auf der AM3-Plattform zu bleiben und die maximal auszubauen.
Da ich ja schon beim Kauf des Mainboards damit gerechnet hatte, ist mein Board (laut Hersteller) für bis zu 140 Watt CPUs ausgelegt. Der FX-8350 mit seiner TDP von 125 Watt sollte also kein Problem darstellen. Und ich wollte auch endlich den boxed Kühler loswerden, der unter Vollast extrem laut wird. Meine Wahl fiel auf eine Cooler Master Seidon 120V rev2 AIO Wasserkühlung. Davon versprach ich mir vor allem einen leiseren Betrieb unter Last. Da die FX-CPUs allgemein in dem Ruf stehen sehr viel Abwärme zu produzieren, wollte ich einfach auf der sicheren Seite sein. Und nicht zuletzt finde ich das eine Wasserkühlung einfach besser aussieht als ein Luftkühler.

Soweit zur Planung. Ich habe also die beiden Teile bestellt und war ganz begeistert als sie endlich ankamen. Zuerst wollte ich mal den Unterschied im Bezug auf den Kühler testen, und habe ihn daher erstmal auf dem FX-4300 montiert. Und da fingen die Probleme an. In meinem Gehäuse (Thermaltake Soprano) gibt es nur zwei Plätze für einen 120er Lüfter, und wie ich feststellen musste sind beide ungeeignet für Radiatoren. An der Front ist der Festplattenkäfig im Weg, während an der Rückseite die Montagelöcher zu nah am Netzteil sitzen. Blöd gelaufen.

Aber so leicht lasse ich mich natürlich nicht aufhalten, und hab den Radiator einfach irgendwie befestigt. Zusätzlich zu Klebegummi an allen vier Ecken brauchte ich noch ein Stück Draht, um den Radiator auch dann noch an seinem Platz zu halten, wenn er richtig warm wird. Die Installation des eigentlichen Kühlblocks auf der CPU war kein Problem, es war nur etwas nervig das ich dafür das Mainboard ausbauen musste. Aber es funktionierte. Die Leistung war aber nicht so gut wie ich gehofft hatte. Die Temperaturen waren sogar etwas höher als zuvor. Aber es lief und war deutlich leiser, selbst mit dem Lüfter auf 100%. Das Problem zeigte sich erst, als ich ein paar Leistungstests machen wollte. Die CPU lief dabei heiß, aber stabil. Aber immer wieder hat sie sich kurzzeitig runter getaktet und dabei sind sogar YouTube Videos ins stottern gekommen. Relativ schnell hat sich dann herausgestellt, das es mein eigener Planungsfehler war. Auf meinem Board sind die Spannungsregler für den Prozessor komplett ungekühlt.


Und auf der Webseite findet sich auch der Hinweis, daß man auf diesem Board nur Lüfter benutzen soll, die die Komponenten auf dem Board mit kühlen. Das ist natürlich hier nicht der Fall, und die Spannungsregler haben sich überhitzt.
Ein "quick&dirty" Fix dafür war der Lüfter vom alten boxed Kühler, den ich neben dem Kühlblock festgeklebt habe. Nicht hübsch, aber funktionierte stabil. Aber noch wollte ich die Hoffnung nicht aufgeben. Wenn ASrock die Kühlkörper eingespart hat, warum dann nicht einfach welche nachrüsten?
Leider hatte ich keine passenden. Und natürlich habe ich auch keinen Wärmeleitkleber, und das Board hat auch keine Löcher in der Gegend die man für eine improvisierte Befestigung benutzen könnte. Aber zuerst mal brauchte ich passende Kühlkörper. Dafür entschied ich mich, einen alten 486er CPU-Kühler zu zersägen. Das war auch kein großes Problem. Problematisch war eher die Befestigung. Mein erster Versuch war, Wärmeleitpaste mit Sekundenkleber zu mischen.

Das war allerdings keine gute Idee. Ein paar Sekunden nach dem Vermischen gab es eine ziemlich heftige chemische Reaktion, eine kleine Rauchwolke und das Gemisch war hart wie Stein. Der nächste Versuch war dann Uhu Alleskleber, und die Mischung hat wirklich funktioniert.
Leider war das nicht genug um die Regler dauerhaft zu kühlen. Die Einbrüche der Taktrate waren immer noch da. Meine Vermutung war eine Kombination aus zwei Faktoren:
Einerseits überdeckte der Radiator mit Lüfter den Bereich der Spannungsregler, andererseits hatte das Gehäuse nur einen einzigen Einlass-Lüfter an einer sehr ungünstigen Position. Das zusammen führte dazu, das die Kühlkörper praktisch keinen Luftstrom abbekommen haben. Also musste ich weiterhin den zusätzlichen Lüfter benutzen. Konnte ihn aber deutlich langsamer laufen lassen. Und obwohl der Kleber bei höheren Temperaturen etwas weich wird, hält es sehr stabil. Und sieht sogar recht ansehnlich aus. Aber eine Dauerlösung war das natürlich nicht. Im Prinzip bleiben da drei Möglichkeiten. Ein neues Mainboard, ein passender Luftkühler, oder eine weniger stromhungrige CPU. Die letzten beiden Möglichkeiten scheiden für mich aber beide aus. Aber das hebe ich mir noch für einen zukünftigen Beitrag auf.

Portfolio Komplettumbau, Teil 1

Ich habe jetzt einige Zeit nichts geschrieben, aber war nicht untätig.

Es sind einige Modifikationen für den Portfolio zusammen gekommen, die ich hier nach und nach vorstellen will. Los geht es mit:

Teil 1: RAM-Erweiterung

Schritt 1.1: Zerlegen

Den Vorgang beschreibe ich nun nicht genauer, es gibt bereits mehrere Anleitungen. Man muß jedenfalls das Mainboard komplett ausbauen.

Schritt 1.2: Auslöten

Dafür benutze ich die etwas gröbere Lötspitze. Zuerst wollte ich die Platine abkleben und jeweils eine ganze Seite des jeweiligen Chips am Stück auslöten. Das hat sich aber als sehr unpraktisch erwiesen, so das ich mich doch entschieden habe die Pins einzeln abzulöten. Dafür hat es sich als zweckmäßig erwiesen von außen nach innen vorzugehen, so das man die Pins in der Mitte des Chips zuletzt ablötet. Dadurch wird einerseits die thermische Belastung der Platine minimiert, und zudem ist das Risiko geringer das man den Chip versehentlich verdreht und dabei Lötpads beschädigt. Beim Auslöten muß man extrem vorsichtig vorgehen.

Trotz großer Sorgfalt haben sich bei mir einige Pads gelöst. Zum Glück ist jedoch keines abgerissen. Nachdem alle vier RAM Chips ausgelötet waren, habe ich festgestellt, das C20 und C21 etwas zu nah an der Position von U7 liegen, und man den Chip nicht ganz auf die Pads bekommt. Daher habe ich

diese SMD-Kondensatoren auf ihren Lötpads ein Stück verschoben um genügend Platz zu schaffen.

Nachdem man auf die gleiche Weise auch U11 (Adress-Decoder) auf der anderen Seite der Platine ausgelötet hat, ist es schon fast geschafft. Wenn man gleichzeitig noch den CF-Steckplatz einbauen will, ist es empfehlenswert gleich noch den Steckplatz für die originalen Speicherkarten zu entfernen. Die etwas längeren Pins kann man ähnlich wie die der Speicherchips auslöten, die kürzeren habe ich einfach direkt an der Platine abgezwickt.

Hinterher habe ich das jedoch bereut. Es wäre sinnvoll auch diese einzeln auszulöten, damit der Sockel weitgehend unbeschädigt bleibt. Der könnte später noch für ein anderes Projekt interessant werden.

Danach ist es Zeit die Lötspitze zu wechseln, für das einlöten und verschalten der neuen Bauteile empfiehlt sich eine möglichst feine Lötspitze. Je dünner desto besser.

In der Zwischenzeit muß man noch einige Pins des neuen RAM-Chips mit äusserster Vorsicht hoch biegen. Das sind genau Pin 1, 2, 22, 30, 31 und 32. Alle anderen Pins werden wir gleich direkt auf die Pads von U7 auflöten. Wenn man schon dabei ist, kann man auch die Pins des 1MB Chips hoch biegen. Ich nehme dafür eine kleine Flachzange, setze sie direkt am Rand des Chips an und drücke die Pins flach. Das geht recht einfach und mir ist dabei noch nie ein Pin abgebrochen.

Schritt 1.3: Einlöten

Verglichen mit dem vorherigen Schritt ist das Einlöten des neuen Chips eine Kleinigkeit. Man

muß nur sehr vorsichtig sein beim Dosieren des Lötzinns, damit man keine Kurzschlüsse verursacht. Und natürlich muss man darauf achten das die zuvor hoch gebogenen Pins keinen Kontakt zur Platine bekommen. Vom 74HC21 biegen wir dann auf der linken Seite alle Pins bis auf den untersten (GND) etwas hoch, und auf der rechten Seite den obersten (Vcc). dann befestigen wir ihn mit einem kleinen Stückchen doppelseitigem Klebeband auf der Platine. Und zwar so, das der Massepin auf dem Massepad von U5 liegt.

Nachdem dieser Pin angelötet ist, verbinden wir zuerst die Betriebsspannung mit dem Vcc-Pin von

U14 oder U15. Den Vcc Pin des neuen RAM-Chips verbinden wir mit dem Vcc-Pad von U5. Es kann nicht schaden zwischendurch die Verbindungen mit einem Durchgangsprüfer oder Widerstandsmessgerät zu überprüfen. Q1, von dem wir den mittleren Pin anzapfen müssen, befindet sich auf der anderen Seite der Platine. Es ist ein kleiner Transistor in der Nähe des PROM-Chips. Also löten wir einen Draht dort an, und führen ihn an der Spule vorbei durch die Platine. Nachdem dieser Draht am 74HC21 angelötet ist, sind noch drei Drähte am DIP-Chip anzulöten. Da die Pads an diesem Chip sehr eng liegen, empfiehlt es sich, dort zuerst einen Draht anzulöten und diesen zum 74HC21 zu ziehen. Dort hat man dann deutlich mehr Spielraum. Nun nicht ungeduldig werden, es fehlen noch vier Adressleitungen. Zwei davon nehmen wir von U3, dem PROM-Chip auf der CPU-Seite. Die anderen beiden von unserem eben verdrahteten 74HC21. Sobald diese vier Pins verbunden sind, ist es Zeit für einen ersten Test. Also bauen wir den Portfolio provisorisch wieder zusammen. Sollte der Portfolio sich mit der Fehlermeldung "Ram Test Failure 000:0BFE" melden, hat man die Adressleitungen vergessen, wie ich bei meinem ersten Versuch. Wenn alles geklappt hat, sieht man beim Einschalten ungefähr das hier:

ATARI Portfolio

Ich habe kürzlich einen ATARI Portfolio bekommen, und war auf Anhieb begeistert.

Es ist so ziemlich der erste PDA. Erschienen 1989, passt in eine Handtasche und ist dabei fast kompatibel zum IBM PC XT. Der Speicher ist, zumindest bei meinem Modell, mit 128 kB sehr knapp bemessen, und richtige Laufwerke fehlen komplett. Er verwendet eigentlich spezielle Speicherkarten, damals CCM (Credit Card Memory) genannt. Das waren keine Speicherkarten wie wir sie heute kennen, sondern praktisch RAM-Chips mit Batterie. Flash Speicher gab es damals noch nicht. Ein Teil des Arbeitsspeichers wird als RAM Disk für ein virtuelles Laufwerk C: verwendet.
 
Das hat den Nachteil das ein "böses" Programm ganz leicht die kompletten Daten löschen kann.
Wie es so meine Art ist, musste ich natürlich sofort probieren was ich an dem kleinen modifizieren könnte. Und es hat sich schon vor einer Ewigkeit jemand die Mühe gemacht einen Steckplatz für CF-Karten in den Portfolio einzubauen. Da ich eine solche noch da hatte und auch einen kaputten Kartenleser als Spender für den Steckplatz, habe ich sofort angefangen.
Meine Versuche einen Flash Chip direkt anzuschließen waren nicht erfolgreich, vermutlich weil der eine bestimmte Kommandosequenz braucht um den Schreibschutz aufzuheben. Aber das schaffe ich vielleicht noch irgendwann. Auch einen PIC Chip direkt einzubauen hat nicht funktioniert. Der bringt die Signale des 80C88 Prozessors durcheinander beim Starten. Aber das schaffe ich noch irgendwann. Jedenfalls hat die Modifikation mit der CF-Karte nach kleineren anfänglichen Schwierigkeiten perfekt funktioniert. Der Treiber dafür funktioniert auch problemlos, und ich habe jetzt zwei zusätzliche Laufwerke mit jeweils 32 MB. Das ist für dieses winzige System reichlich. Aber da wurde es erst interessant. Da ich nun einen festen Speicher hatte, wollte ich natürlich auch ein paar Programme. Also ging die Suche los. Onkel Google war dabei sehr hilfreich, und es hat nicht lange gedauert bis ich einiges an Software hatte. Und wie es bei mir so üblich ist, kamen auch recht schnell die ersten Ideen auf was man noch alles machen könnte. Also ging ich auch auf die Suche nach einem C-Compiler, der nicht nur Code für den Portfolio erstellen kann, sondern auch noch auf dem Portfolio selbst laufen sollte. Das war schon etwas kniffeliger, aber nach einiger Suche bin ich auf DeSmet C gestoßen. Zuerst in Form der abgespeckten Shareware von 1988 oder so, aber dann habe ich auch die inzwischen freigegebenen Vollversionen gefunden. Und siehe da, der Portfolio kann auch kompilieren. Die neueste Version ist etwas zu speicherhungrig, die werde ich wohl erst nutzen können wenn ich der Arbeitsspeicher erweitert habe. Das steht ganz oben auf meiner Liste, zusammen mit einer Hintergrundbeleuchtung für das Display. Was mich aber wirklich begeistert ist wie sparsam der kleine ist. Obwohl ich ihn relativ oft benutze und auch den Parallelport dran habe, der angeblich recht viel Strom braucht, halten die Batterien fast eine Woche. Betrieben wird er nicht mit speziellen Akkus, sondern mit drei herkömmlichen AA-Zellen.
Und heute habe ich schon das erste Stückchen Software für den Portfolio veröffentlicht. Mit Hilfe des technischen Referenzhandbuchs habe ich ein paar der speziellen BIOS-Funktionen des Pofo und einige DOS-Funktionen in eine C-Bibliothek verpackt und auf Github gestellt. Bin mal gespannt ob meine libPofo jemandem von Nutzen sein kann.

DevelOS Struktur

Ich habe mal ein Diagramm erstellt um die grundlegende Struktur von DevelOS aufzuzeigen.
Leider ist es im Moment nicht wirklich so lauffähig, wie ich es gerne hätte. Bei der erweiterung habe ich wohl einige inkompatibilitäten erzeugt, und die Performance lässt auch stark zu wünschen übrig. Teile des Systems werde ich wohl neu schreiben müssen. Aber die Struktur will ich gerne so belassen. Noch rot eingezeichnet ist das Konsolen-Modul. Das habe ich erst jetzt implementiert. Mir ist aufgefallen das der Zugriff auf den Buffer des Display-Moduls problematisch sein kann. Außerdem hätte ich die gesamten Ausgabe-Routinen für den UART nochmal neu schreiben müssen. Also habe ich mich entschloßen den Buffer und die Ausgabefunktionen aus dem Display-Modul heraus zu nehmen. Dieses Modul macht jetzt nur noch die Initialisierung und das Übertragen vom Konsolenbuffer in den Hardware-Puffer des jeweiligen Display Moduls. Allerdings ist da noch so einiges im argen. Ich glaube ich habe da noch jede Menge Speicherlöcher drin.

DevelOS Struktur

Wie man hier sieht belegt DevelOS selbst einen großen Teil der externen Schnittstellen des PIC. Es verwaltet den Taktgenerator, die AD Wandler und das EEProm. Über IO-Pins können weitere Geräte angebunden werden.

Freestyle-I2C

Im Moment habe ich an meiner Testplatine ein 4x20 Zeichen LCD Display angeschloßen, sowie zwei kleine I2C-EEproms. Eines ist ein Atmel 32kbit-EEPROM das nur eine Bus-Adresse hat, aber intern mit 16bit Adressen arbeitet. Das andere ist ein ST 8kbit, das intern mit 8 bit adressiert wird, dafür aber in 4 Bänke unterteilt ist, die jeweils über eigene Bus-Adressen angesprochen werden. Eine gute Möglichkeit, um einen wirklich universellen Treiber zu schreiben, der beide EEPROMs ansprechen und für das DevelOS einheitlich darstellen kann. Sie sind zwar etwas abenteuerlich angeschloßen, aber im Prinzip funktioniert es. Den UART habe ich auf eine Buchse heraus geführt, aber bisher funktioniert er nicht richtig. Da der PIC im Moment nur mit dem internen Oszillator läuft, ist die Baudrate wohl zu ungenau. Die Buchse habe ich von einem alten Mainboard geerntet. Eigentlich ist es ein Audio-Anschluß für ein CD oder DVD Laufwerk. Die drei belegten Pins machen ihn aber für alles mögliche einsetzbar, und die etwas besseren Kabel für diesen Port sind sogar abgeschirmt. Damit will ich später mal die

Verbindung von diesem PIC-Board zu meinem Server herstellen. Auf dem Bild hier links sieht man das Display, und die zwei Ports die ich eben beschrieben habe. Der linke, schwarze davon ist an den UART angeschloßen, der andere ist noch nicht belegt. geplant hatte ich dort den I2C-Bus heraus zu führen, um zusätzliche Chips mit anbinden zu können. Ganz am linken Rand sieht man oben den Anschlußblock für die Stromversorgung und den Anschluß der Lüfter, die der PIC einmal regeln soll. Die Stiftleiste rechts neben den Widerständen ist ein Anschluß für die Spannungen des ATX-Netzteils. Diese soll der PIC ebenfalls überwachen und dem Banana Pi über den UART mitteilen. Unter dem Anschlußblock links sieht man auch noch zwei Transistoren die ich ebenfalls von alten Mainboard habe. Für die Steuerung von Lüftern sind sie mit einer Schaltleistung von über 100 Ampere zwar völlig überdimensioniert, aber hey, was nichts kostet ist auch nicht verschwendet.


Zwischen dem Anschlußblock und dem Kabel für das Display sieht man noch den Anschluß für das Programmiergerät. Dafür verwende ich eine ehemalige PS2-Buchse. Ich wollte mein Programmiergerät nicht jedes mal wieder an eine Stiftleiste anschließen, sondern eine komfortable Möglichkeit haben ein Gerät auch von außen zu Programmieren.

Der weitere Ausbau gestaltet sich jedoch schwierig, da das Programm jetzt nur noch etwas mehr als 100 mal pro Sekunde durch läuft. Dabei wird aber schon zwei mal das Display neu geschrieben und einige Timer laufen. Es kann jedoch noch einiges optimiert werden. Zum Beispiel wird die Uhr im Moment von einem 8-bit Timer abgeleitet mithilfe eines Software-Zählers. Das ist extrem ineffizient. es wäre deutlich besser hierfür einen 16-bit Timer mit entsprechenden Preloadwerten zu verwenden.Und wenn ich mir die Zeit nehme, finde ich bestimmt noch hundert weitere Möglichkeiten zur Optimierung. Leider habe ich das Profiler-Plugin für MPLab-X nicht, und will auch keine 45 Euro dafür bezahlen. Also werde ich wohl so zurecht kommen müssen.

Hier nochmal ein Link zum Projekt auf Github: https://github.com/Stefanie80/DevelOS.X/tree/experimental

DevelOS auf github

Ich habe mein DevelOS jetzt auf github veröffentlicht.
Am Anfang war es noch etwas gewöhnungsbedürftig, aber ich hab die Bedienung hin bekommen.

Leider läuft das System so wie es gerade ist nicht richtig. Vermutlich wird irgendwo eine Variable überschritten oder so, aber das habe ich auf die schnelle nicht gefunden. Es tritt interessanter Weise nur im production Image auf, das Debug Image läuft gut.

Die Sources sind hier zu finden: https://github.com/Stefanie80/DevelOS.X

Hoffe das es noch jemandem was bringt ...

Download-Server im Einsatz

Ich hatte ja schon angekündigt, das ich in absehbarer Zeit ein Howto erstellen will, wie man einen Homeserver selbst konfiguriert. Dafür werde ich dann natürlich meinen vorhandenen Banana Pi einsetzen. Aber noch ist es nicht so weit. Ich habe den Server ja erst kürzlich zerlegt, und bevor ich das nochmal mache, möchte ich ein bisschen was vorbereiten. Auf jeden Fall will ich dann gleich das aktuellste Betriebssystem verwenden, und die Einrichtung dann Schritt für Schritt dokumentieren. Und auch an der Hardware will ich noch ein bisschen was verändern. Heute soll es aber erstmal um die Vorbereitung gehen. Und dabei kann ich auch gleich zeigen, wie und wofür man so einen Server sehr gut einsetzen kann. Einer der wichtigsten Punkte ist für mich die Downloadverwaltung. Und die wird heute zum Einsatz kommen.Die aktuellste Version von Bananian gibt es hier: https://www.bananian.org/download

Im Moment ist das Debian 8 Jessie. Die Datei ist zwar "nur" 158 MB groß, das wäre noch an der Grenze dessen was ich lokal auf dem Desktop runter laden würde. Aber heute mache ich es gleich über Torrent, um den Vorgang mal zu zeigen.
Wie man auf dem Screenshot sehen kann, gibt es auf der Seite von Bananian nur einen direkten Link auf die ZIP-Datei. Man kann aber trotzdem Torrent verwenden, dafür gibt es die Seite http://burnbit.com/. Man klickt auf einen beliebigen Download-Link mit der rechten Maustaste, und wählt dann den Punkt "Link-Adresse kopieren".
Dann geht man auf die Seite von Burnbit, und fügt den Link in die Zeile oben ein.

Hier muß man ein bisschen aufpassen, denn es werden nur reine http-Links unterstüzt. In diesem Fall ist es ein https-Link, der würde so nicht funktionieren. Aber in den meisten Fällen klappt es trotzdem, wenn man das 's' einfach löscht.
So klappt es auch hier. Danach öffnet sich die Download-Seite mit einigen Infos zur Datei.
Hier finde ich den Punkt "Added:7 months ago" besonders interessant. Das heist ich bin nicht die erste, die Burnbit verwendet um diese Datei zu laden, jemand hat sie schon vor 7 Monaten hinzugefügt.

Ein klick auf "Download Torrent" startet dann den Download. Falls die Datei noch nicht bei Burnbit registriert ist, erscheint in diesem Fenster oben ein Forstschrittsbalken, während die Datei verarbeitet wird. Dabei wird sie in viele kleine Teile unterteilt und für jedes Teil wird eine Prüfsumme berechnet, so das man sie von mehreren Quellen gleichzeitig herunterladen kann, aber trotzdem die Integrität der Datei sichergestellt ist. Warum das wichtig ist, werdet ihr gleich noch sehen. Jetzt geht es aber erstmal ans runterladen:

Ich wähle hier direkt "Öffnen mit ...". Wie man sieht wird nun eine Größe von nur knapp 50kb angezeigt. Was man hier herunter lädt, ist nur eine sogenannte Metadatei. Sie enthält Prüfsummen der Datei und Angaben dazu, wo sie zu finden ist. Nach dem Klick auf OK öffnet sich Deluge mit dem Dialog zum Hinzufügen eines neuen Torrents. Hier kann man auch gleich ein paar Einstellungen vornehmen, wie zum Beispiel den Zielordner. Sobald man die Datei hinzugefügt hat, legt Deluge direkt mit dem Download los.

 Allerdings läuft der Download selbst auf dem Server, nicht auf meinem PC. Den könnte ich jetzt auch ausschalten.
Wozu der Umweg? Naja, bei dieser Datei ist die geschätzte Downoaldzeit nur gut 10 Minuten, da lohnt es sich kaum. Es sei denn man will in der Zeit etwas anderes Nebenbei machen. Deluge bietet nämlich unter anderem die Möglichkeit, die Up- und Downloadgeschwindigkeit zu bestimmen. Ich habe hier nur eine 6000er DSL Leitung, also kann ich im besten Fall mit etwa 700 kb/s laden.

Das ist nicht viel, und selbt ein einzelner Download kann dazu führen, das nebenher nichts anderes mehr funktioniert, oder YouTube die Videoqualität auf 144p drosselt. Ich habe den Deluge allerdings auf 230 kb/s gedrosselt, so das mir immer noch zwei Drittel der Leitung frei bleiben. Ich könnte jetzt auch noch beliebig viele weitere Torrents hinzufügen, Deluge erledigt die dann gleichzeitig. Man muß sich nicht darum kümmern, das läuft alles wie von selbst. Man kann die Geschwindigkeit auch zeitabhängig einstellen, so wie ich. Tagsüber, von morgens um 7 bis Nachts um 12 ist die Geschwindigkeit gedrosselt, so das ich immer problemlos surfen und Videos schauen kann, und von 0 Uhr bis 7 Uhr morgens darf dann Deluge die Leitung komplett ausnutzen.

Das kann man im Scheduler-Plugin auch noch für jeden Tag der Woche einzeln genau konfigurieren, und man kann auch einzelne Stunden komplett verbieten, dann ist das Feld rot. Das ist zum Beispiel sinnvoll, wenn man regelmäßig zeitgesteuerte Updates durchführen lässt. So kann man sicherstellen, das die immer mit der höchsten Geschwindigkeit laufen. Hat man mehrere Rechner, so wie ich, dann legt man die Updates am besten auf jedem Rechner auf einen anderen Wochentag, aber in die gleiche Stunde, und stellt dann die entsprechenden Stunden im Deluge auf rot. Sobald der Download abgeschloßen ist, steht im Fortschrittsbalken "Seeding". Das heißt das mein Rechner jetzt dabei mithilft, die Datei zu verteilen.

 Lädt jemand anders jetzt die gleiche Datei, so verbindet sich sein Rechner nicht nur mit dem Original-Server, sondern zusätzlich auch mit meinem Rechner. Er bekommt dann von mir ein paar Kilobyte pro Sekunde zusätzlich. Wenn es nur einen sogenannten Seed gibt, bringt das natürlich nicht viel, aber bei populären Dateien gibt es auch mal hunderte Seeds, so das man mit Torrent auch deutlich höhere Geschwindigkeiten erzielen kann. Diese Technik setzen zum Beipsiel die meisten Online-Spiel ein, um ihre regelmäßigen Updates zu verteilen. 
 
Nur das man dort nichts davon sieht, und den Vorgang auch kaum beeinflussen kann. Man braucht übrigens nicht immer Burnbit dazu. Viele Anbieter haben die Vorteile von Torrents inzwischen erkannt, und bieten gleich selbst entsprechende Downloads an.Dazu zählen etwa die Raspberry Foundation oder auch OpenSUSE. Ich möchte bei Gelegenheit auch noch das neueste SuSE Linux als Zweitsystem auf meinem Desktop installieren, dafür gibt es wie ihr seht direkt den Link auf BitTorrent.

Und hier sieht das Bild jetzt etwas anders aus: mein Rechner hat sich mit 94 anderen verbunden, und bekommt von jedem ein paar Kilobyte pro Sekunde. Die einzelnen Benutzer bemerken die wenigen kb gar nicht, aber ich kann die Datei trotzdem mit voller Geschwindigkeit laden. Bei der momentanen Geschwindigkeit wird das wohl über 5,5 Stunden dauern. Aber wie gesagt, das läuft auf dem Server, und ich muß meinen Rechner nicht die ganze Zeit laufen lassen.

DevelOS

Neben meiner Bastelei an PCs und meinem lokalen Netzwerk, beschäftige ich mich seit ein paar Jahren auch immer wieder mit der Programmierung von Microchip PIC Microcontrollern. Was ich daran besonders faszinierend finde ist die direkte verschmelzung von Code und Hardware, und das man damit quasi jedes Stückchen Elektronik irgendwie nutzen und ansprechen kann.
Inzwischen habe ich auch schon eine Menge kleinere Projekte umgesetzt, leider sind meine, teilweise sehr ausführlichen, Posts dazu verloren gegangen als blog.de abgeschaltet wurde.

Heute möchte ich etwas vorstellen was eigentlich eher ein Meta-Projekt ist. Wer sich mit PICs beschäftigt wird meistens recht schnell merken, das man bestimmte Funktionen immer wieder braucht, und dank der Programmierbarkeit in C kann man das meiste auch wiederverwenden. Aber dann muss man es immer wieder in ein neues Projekt kopieren, und mit neuen Funktionen zusammenbringen. Natürlich geht das, aber ich fand nach einiger Zeit ziemlich umständlich.

Daher habe ich irgendwann mal eine Art minimales Betriebssystem gebastelt, das beinahe beliebige Aufgaben erfüllen kann. Der Kern davon ist eine Pipeline, in die Nachrichten gesetzt werden können, die dann der Reihe nach abgearbeitet werden. Das passiert in einem einzigen langen switch()-Statement, das für jedes definierte Event ein Stückchen Code enthält.

Ein Beispiel:

Man verwendet einen AD-Kanal und möchte diesen periodisch auslesen. Am effektivsten geht das, indem man die Konvertierung startet, und dann auf den Interrupt wartet das der AD fertig ist. Dann bekommt man die Rohdaten zurück, die man dann umrechnen muß, um den tatsächlichen Wert zu erhalten. In meinem System sind das mehrere Events.

1. Das RTC-Modul meldet, das eine bestimmte Zeitspanne abgelaufen ist.
2. Dies löst ein Event aus um eine neue Konvertierung zu starten
3. Der AD konvertiert, die Rückgabe erfolgt per Interrupt
4. Im Interrupthandler wird nur ein neues Event erstellt, das die Rohdaten enthält
5. Die Rohdaten werden konvertiert, das Ergebnis wird wieder als Event in die Pipeline geschrieben
6. Je nach Funktion kann dieses Event wieder neue Events triggern, die Ausgabe auf ein Display z.B.

Das sieht auf den ersten Blick vielleicht etwas kompliziert aus, und mancher wird sich denken "Aber ein PIC hat doch gar keine RTC!". Nun, die RTC war eine der ersten Funktionen die ich auf diese Weise implementiert habe. Ein 16bit-Timer löst einen Interrupt aus, das wird als Event in die Pipeline geschrieben, und löst das hochzählen der RTC aus. Dort können wiederum andere Events ausgelöst werden. So kann man zum Beispiel angeben, das die Refresh-Routine für ein Display in einem bestimmten Intervall aufgerufen werden soll.

Das ist der Kern des DevelOS. Darum herum habe ich dann einige Module gebaut, z.B. das RTC-Modul, mehrere Module um Displays anzusprechen, ein Modul zur Verwaltung des internen EEProm und ähnliches. Um nicht jedes mal unnötig viel Speicher im PIC zu belegen, habe ich das ganze mit #define-Statements und #ifdef-Blöcken organisiert, so das man nur wenige Zeilen verändern muß um ganze Codeblöcke zu aktivieren, die über ettliche Dateien verteilt sein können.

Neben dieser rudimentären Modularisierung erreicht man auf diese Weise auch noch ein relativ gut funktionierendes Pseudo-Multitasking. Weil alles über die Pipeline läuft, können mehrere Aufgaben quasi nebeneinander laufen. Man muß nur aufpassen das man sie in möglichst kleine Stückchen zerlegt, so das der Chip mit einem einzelnen Event nicht zu lange hängen bleibt. In dem obigen Beispiel könnte man ja auch die Umrechnung des AD-Wertes direkt in der Interrupt-Routine unterbringen, aber das könnte eventuell die RTC aus dem Takt bringen.

Vielleicht erstelle ich dafür auch irgendwann ein Github-Projekt, mal sehen. Falls jemand Interesse an dem Code hat, darf mich gerne per Kommentar o.ä. kontaktieren, prinzipiell bin ich gerne bereit den Code zu teilen, unter der Bedingung, das darauf aufbauender Code wieder dem Gesamtprojekt zugute kommt.

Vinculum II

Es ist Zeit, mal den Aufbau meines Servers zu zeigen. Ich habe ihn vor ein paar Tagen mal wieder abgeschaltet und aufgemacht, vor allem um die Kabel etwas ordentlicher zu verlegen und ein XBee-Funkmodul anzuschließen. Dabei habe ich dann auch einige Fotos gemacht, so das ich jetzt hier ein bisschen was zeigen kann.

Hier sieht man das Herz des Servers, den Banana Pi. Links befinden sich die beiden USB-Ports und der Netzwerkanschluß, rechts sieht man die SD-Karte auf der sich das Betriebssystem befindet. Das war vorher eine 4 GB Karte, die eigentlich auch ausreicht. Nur habe ich inzwischen viele zusätzliche Funktionen eingebaut, es kommen auch immer wieder Updates, und so waren nur noch rund 800 MB frei. Das hätte noch lange ausgereicht. Jetzt gab es aber hier bei einem örtlichen Elektronikhändler eine 32 GB Karte für gerade mal 10 Euro im Angebot, und die war auch noch deutlich schneller als die ursprüngliche. Da habe ich natürlich sofort zugeschlagen und habe jetzt wieder reichlich Reserve.
Ganz vorne im Bild sieht man ein buntes Kabel, das ist eine der drei seriellen Schnittstellen des Banana, an die ich das XBee-Modul angeschloßen habe. Praktischerweise sind hier die beiden Datenleitungen, eine 3,3V und eine Masseleitung direkt nebeneinander, so das ich das Modul komplett mit diesem einen Kabel betreiben kann. Hinten sieht man noch das weiße µUSB-Kabel, das nur zur Stromversorgung dient, und daneben das rote SATA-Kabel. Darüber hinaus hat der Banana noch einen HDMI, einen Composite Videoausgang und einen Soundausgang, die ich aber nich verwende. Vielleicht werde ich irgendwann noch einen Lautsprecher einbauen für Fehler- und Statusmeldungen, aber das ist eine andere Geschichte.
Ganz rechts oberhalb der SD-Karte sieht man noch einen µUSB-Port, das ist auch nochmal ein vollwertiger USB2.0-Port den ich später nutzen könnte, wenn ich ihn denn brauche.

Und hier seht ihr den Server im Überblick. auf den ersten Blick wirkt das sehr chaotisch, vor allem wegen der Kabel. Links unten ist die ganze Stromverkabelung. Ich habe hier eine ATX-Buchse aus einem alten Netzwerk verwendet, und daran alle Kabel angelötet die ich so brauche. Einige Spannungen habe ich auf eine Schraubklemme geführt, das macht es etwas einfacher das System zu erweitern. Das grüne was man unten sieht, ist ein 8-Port Netzwerk Switch, und darüber sieht man einen der beiden USB2.0-Hubs. Dieser ist mit vier Festplatten bereits voll belegt, der zweite rechts unten steht für die nächsten Platten zur Verfügung. Es wäre vermutlich effizienter die Platten auf beide Hubs zu verteilen, aber ich bin mir nicht ganz sicher ob das nicht mein LVM-Setup durcheinander bringen würde. Doch dazu später mehr. Unten rechts sind auch zwei 3,5"-Festplatten montiert, jeweils 1 TB. Beide habe ich als USB-Festplatten gekauft und dann aus dem jeweiligen Gehäuse ausgebaut. Das war billiger als die Platten und USB-Adapter einzeln zu kaufen. Die Stromversorgung kommt dabei jeweil direkt aus dem ATX-Netzteil oben links. 

Und hier ein Blick in den oberen Laufwerkskäfig. Man sieht unten die 3,5" SATA-Platte mit 2TB, darüber sind zwei Montagerahmen eingebaut die jeweils vier 2,5"-Laufwerke aufnehmen können. Zwei Stück mit jeweils 1TB sind bereits vorhanden. In Einzelhandels-Byte sind somit 6TB verbaut, allerdings bleiben davon nach der Umrechnung nur noch etwa 950 Gigabyte bei den 1TB Platten und 1900 Gigabyte bei der 2TB Platte übrig, also zusammen ca. 5722 Gigabyte. Ein bisschen ist für das System selbst reserviert (gemountet als /var) und ein bisschen geht noch für das Dateisystem drauf, so das am Ende 5,35 "echte" TB als Netzlaufwerk zur Verfügung stehen.
Ich habe hier noch 6 Monatgeplätze für weitere Festplatten frei, und im Laufe der Zeit werde ich die auch sicher bestücken. Allerdings ist das immer eine Geldfrage, auf so eine Platte muß ich schon eine Weile sparen. Außerdem will ich auch den Netzwerk-Switch durch einen mit Gigabit-Ethernet ersetzen, damit ich den Banana wirklich mal ausreizen kann. Im Moment wird die Leistung eigentlich nur durch das 100MBit-Netzwerk begrenzt. Ich erreiche mit diesem System sowohl beim Lesen als auch beim Schreiben konstant 11-12 MB/s, also wirklich das Maximum was das Netzwerk hergeben kann. 

Hier rechts nochmal der Server im endgültigen Zustand mit der FritzBox oben drauf. Vom unteren USB-Hub habe ich ein Kabel nach außen gelegt, das ist aber im Moment nicht belegt. Ich möchte einfach die Möglichkeit haben eine externe Festplatte anzuschließen, falls mal ein Freund etwas größeres kopieren möchte. Das geht über WLAN nur sehr langsam, und extra Kabel legen ist mir zu nervig.
Das aufgerollte Netzwerkkabel links unten verbindet die FritzBox mit dem Switch, ich habe nur die überschüssige Länge im Gehäuse versteckt, damit es von außen etwas ordentlicher wirkt. Und wenn man genau hin schaut, sieht man oben rechts das kleine XBee-Funkmodul. Darüber werde ich irgendwann noch einen eigenen Post schreiben.

Hier noch die Front- und Rückansicht. Vorne habe ich zwei Lüfter angebracht, vor allem um die Festplatten zu kühlen. Die erreichen vor allem im Sommer schon recht bedenkliche Temperaturen. Hinten sieht man die beiden Netzwerkkabel rot ist der Server und weiß die Fritzbox. Und hier sieht man auch nochmal das Funkmodul, das ich einfach mit Panzertape am Gehäuse befestigt habe. Simpel aber effektiv. Man sieht auch das ich (fast) sämtliche Öffnungen des Gehäuses mit Paketband abgeklebt habe. Dadurch will ich einen kontrollierten Luftstrom sicherstellen. Die beiden Lüfter in der Front versorgen die Festplatten mit Frischluft, und das Netzteil hinten zieht die Luft wieder aus dem Gehäuse. Der Banana ist dabei so Montiert, das sein Kühlhörper direkt im Luftstrom des Netzteils liegt.

So, das wars vorerst mal. Aber es kommt sicher irgendwann noch mehr dazu.

Banana Pi vs. Raspberry Pi

In meinem letzten Post dazu habe ich ja schon geschrieben das ich zeitweise einen Raspberry Pi für meinen Homeserver benutzt habe. Und das ich jetzt einen Banana Pi verwende, der deutlich mehr Leistung hat. Aber warum das so ist, das habe ich nicht genau erklärt. Das will ich jetzt nachholen, weil es da oft ein Mißverständnis gibt.
Natürlich ist der Prozessor immer ein Faktor, und der Raspberry hat nur einen Singlecore mit maximal 1000 MHz. Von Hause aus läuft er sogar nur mit 700 MHz. Der Banana Pi dagegen hat einen Dualcore mit bis zu 1200 MHz. Das ist aber nur die halbe Wahrheit. Denn wenn es nur darum geht, Daten im Netzwerk herum zu kopieren, spielt die Prozessorleistung nur eine untergeordnete Rolle. Aber was ist dann der Grund, das der Raspberry nur gut 2 MB/s schafft, der Banana aber ganz locker 12 MB/s durch das 100 MBit Netzwerk schiebt?
Dazu muß man sich vor Augen halten, das beide Rechner auf einem sogenannten SoC beruhen. SoC steht für "System on a Chip", das bedeutet das hier ein ganzes System in einem einzelnen Chip steckt. Bei einem PC hat man einen Prozessor, und einen Chipsatz, oder auch Northbridge genannt. Diese Northbridge stellt alle Verbindungen innerhalb des Systems bereit, also heutzutage vor allem USB-Ports, SATA-Ports, PCI-Express-Anschlüsse, Netzwerkport, eben alles was man so braucht. Früher gab es auch noch eine sogenannte Southbridge, die den Arbeitsspeicher angesteuert hat. Diese Funktion ist aber inzwischen fast immer im Prozessor integriert.
Nun, bei einem SoC sind alle Komponenten in einem einzelnen Chip integriert. Nach aussen haben diese Chips meist einige spezielle Ports, wie z.B. HDMI, einige serielle Schnittstellen wie I2C und SPI, über die man andere Chips ansteuern kann, und insbesondere USB-Ports. Letztere sind für uns interessant, da wir hier unsere Festplatten und so weiter anschließen. Und auch der Netzwerk-Anschluß ist bei den beiden von mir betrachteten Systemen jeweils per USB angebunden. Wenn man weiß, das quasi alle Geräte bei einem Raspberry oder Banana per USB angesprochen werden, dann stellt sich unweigerlich die Frage, wieviele Ports hat denn das jeweilige SoC eigentlich, und wie sind die aufgeteilt?
Der Raspberry Pi basiert auf einem Broadcom BCM2835 SoC, das nach außen hin nur einen einzigen USB-Port hat. Dieser wird auf einen Chip geführt, der den Netzwerkanschluß und die externen USB-Ports bereit stellt. Wie man hier nachlesen kann, ist das bei allen Modellen des Raspberry bis heute genau gleich geblieben. Alle externen USB-Ports und das Netzwerk teilen sich also einen einzigen USB-Port.
Beim Banana Pi kommt dagegen ein Allwinner A20 SoC zum Einsatz, das nach außen über drei USB-Ports verfügt. Zusätzlich hat dieses SoC auch direkt einen Netzwerkanschluß und einen SATA-Port. Nachzulesen hier. Das heißt, beim Banana Pi sind alle USB-Ports eigenständig und bieten die volle Bandbreite, unabhängig von den anderen Anschlüssen.
Und genau das macht den großen Unterschied aus.

Vinculum

Wer mich persönlich kennt, der weiß das ich schon seit ca. 10 Jahren immer einen eigenen Homeserver betrieben habe.
Dafür kam im Lauf der Jahre immer wieder andere Hardware und Software zum Einsatz. Da ich meinen aktuellen Server in der nächsten Zeit mal wieder überarbeiten werde, will ich hier erstmal einen Überblick geben warum und wie ich den Server betreibe.

Zuerst mal das "Warum?". Natürlich eine berechtigte Frage. Für die Verwaltung des eigenen Heimnetzwerkes gibt es jede Menge verschiedene Router die ihren Job meistens recht zufriedenstellend erledigen. Will man Dateien für mehrere Geräte verfügbar machen, z.B. für den PC, das Smartphone und das Tablet, gibt es dafür wirklich gute und einfache NAS-Geräte, NAS steht für Network Attached Storage, zu deutsch grob "(ans) Netzwerk Angeschlossener Speicher". Also eigentlich könnte man auf einen Server ja verzichten. Ja, im Prinzip schon.

Aber aus mehreren Gründen will ich das nicht:

1. Kontrolle
Ich habe gerne die totale Kontrolle über alles, was in meinem Netzwerk passiert. Das ist mit einem herkömmlichen Router meist nur eingeschränkt möglich. Zum einen hat man auf einem dedizierten Server mehr Kontrolle über die Einstellungen, zum anderen hat man dort meistens viel ausführlichere Logfiles, so das man eventuelle Fehler leichter zurück verfolgen kann.

2. Spielraum
Ein Router in Kombination mit einem NAS gibt einem zwar auch die grundlegenden Funktionen eines Servers, aber man ist auf den Funktionsumfang festgelegt, den der jeweilige Hersteller vorgesehen hat. Auf einem Router kann man keine zusätzliche Software installieren, und ein NAS kann nur eine begrenzte Anzahl von Festplatten aufnehmen.

3. Effizienz
Für einen Router, ein NAS, eventuell noch einen Netzwerk-Switch oder eine externe USB-Festplatte braucht man jeweils ein eigenes Netzteil. Die haben dann jeweils eine Verlustleistung, und die addiert sich natürlich bei mehreren Geräten. In einem dedizierten Server hat man dagegen nur ein einziges Netzteil, so das Verluste nur an einer Stelle anfallen und bei geeigneter Wahl des Netzteils sehr gering ausfallen.

4. Ordnung
Wie schon erwähnt, für jedes einzelne Gerät braucht man ein eigenes Netzteil, und dann wollen ja alle Geräte untereinander auch noch eine Datenverbindung haben. Das ufert ganz schnell in einen regelrechten Kabelsalat aus. Und der ist nicht nur sehr unschön, sondern kann auch extrem nervig sein wenn man etwas ändern oder erweitern möchte.

Fazit: Ein Homeserver macht irgenwie doch Sinn.

Meine Server habe ich die meiste Zeit mit Linux als Betriebssystem betrieben. Namentlich SuSE Linux und Debian. SuSE lief auf meinen ersten Servern. Einer der ersten war ein Celeron 400 in einem Booksize-Gehäuse. Die Wahl fiel damals auf SuSE weil ich damit schon auf dem Desktop etwas Erfahrung hatte, und sich die damals aktuelle SuSE noch auf wenige 100 MB "eindampfen" ließ. Eine grafische Oberfläche brauchte ich nicht, das System sollte nur stabil und zuverlässig laufen. Damals hatte ich noch keine großen Festplatten, so hatte der Server nur etwa 20 GB Speicher. Davon wollte ich möglichst viel frei haben, um Daten auszutauschen. Und ein schlankes System bedeutet auch weniger Updates und weniger Fehlerquellen. Lange Zeit war ich damit wirklich zufrieden, allerdings hat das Mainboard nach einem Umzug nicht mehr funktioniert, und ein neuer Server musste her.
Da habe ich dann einen Minitower mit einem älteren Pentium Rechner bestückt. Die genauen Spezifikationen weiß ich inzwischen gar nicht mehr. Nachdem ich den lange Zeit wieder mit Linux betrieben habe, wollte ich irgendwann man Bitcoins minen, und das habe ich beim besten Willen nicht zum laufen bekommen. Und da auf meinen Rechnern sowieso die meiste Zeit Windows lief, habe ich dann mal einen Windows-Server betrieben. Dafür kam ein Windows Small Business Server 2003 zum Einsatz, für das ich die Lizenz schon einige Zeit herum liegen hatte. Was mir gut gefallen hat war die Verwaltung mehrerer Windows PC's in einer Domäne. Dabei kann man wirklich auf praktisch alle Funktionen und Einstellungen der angeschloßenen Rechner zugreifen, bis hin zu Einstellungen in der Registry. Und man kann auch viele Einstellungen für alle Rechner gemeinsam festlegen und Verwalten. Aber, die Einstellungen sind oft tief im System vergraben, und wenn man sich nicht wirklich auskennt, muß man viele Optionen sehr mühsam suchen. Und, damit man vernünftig mit dem System arbeiten kann, ist man auf die Remote-Desktop Steuerung angewiesen. Die funktioniert zwar wirklich gut, aber man braucht eben immer ein volles grafisches Windows System, um darauf zugreifen zu können. Ich habe meine SSH vermisst. Zudem hat der PC als Server wirklich viel Strom verbraucht, was mich irgendwann echt in Schwierigkeiten gebracht hat.

Und irgendwann habe ich dann den Raspberry Pi entdeckt. Ein Linux-Rechner in Scheckkartengröße, mit stromsparender ARM-Architektur. Zwar nicht besonders leistungsstark, aber für meine Zwecke fast perfekt. Zwar entstand daraus das übelste Kabelchaos aller Zeiten, aber das war für mich erträglich, weil ich alles zusammen in einer kleinen Abstellkammer unterbringen konnte, so das es quasi unsichtbar war. Der Rapberry mit eigenem Netzteil, eine USB-Festplatte mit eigenem Netzteil, ein Netzwerk-Switch mit eigenem Netzteil, eine Fritzbox mit eigenem Netzteil. Und ein paar Netzwerkkabel. Wirklich ziemliches Chaos, bei dem ich selbst zeitweise den Überblick verloren habe. Aber es hat gut funktioniert, obwohl die Datenraten immer relativ schlecht waren. Mehr als 2MB/s ging nicht beim Zugriff auf die USB-Platte über das Netzwerk. Das hatte mehrere Gründe, aber es war für mich soweit eigentlich genug. Ausreichend um Videos über das NJetzwerk zu schauen, was für mich bis heute eine der wichtigsten Funktionen des Servers darstellt. Damals noch mit einer modifizierten X-Box als MediaCenter. Und ein weiterer Einsatzzweck kam dazu, nämlich das abwickeln größerer Downloads. Ich habe eine relativ langsame Internetverbindung mit nur knapp 7 Mbit, und da dauert es schon eine kleine Ewigkeit wenn man ein größeres Linux-Image für den Raspberry laden will, oder gar ein DVD-Image für ein Desktop-Linux. Auch habe ich irgendwann angefangen eine Sammlung von Vorlesungen anzulegen, da sind wirklich viele auf archive.org verfügbar. Alle diese Sachen sind per Torrent verfügbar, da lag es nahe einen Torrent direkt auf dem Raspberry laufen zu lassen. Dadurch musste ich nichtmehr meinen großen Desktop PC dauernd laufen lassen, und große Downloads konnten über Nacht laufen wo sie mich nicht gestört haben.

Das führte dazu, das jemand anderes gerne auch eine solche "Seedbox" haben wollte, wie man einen Torrent-Server auch manchmal nennt. Allerdings hatte er keinen Raspberry, sondern einen Banana Pi, ein sehr ähnliches aber deutlich leistungsstärkeres System. Das Board für die Entwicklung eines passenden Images wurde mir großzügigerweise zur Verfügung gestellt, und verrichtet bis heute seinen Dienst in meinem aktuellen Server. Und irgendwann habe ich auch das Kabelchaos endgültig beseitigt. Dafür habe ich ein ATX-Netzteil verwendet, in einem normalen Minitower Gehäuse. Allerdings mit einem selbstgelöteten Kabelbaum, an einem ATX-Stecker aus einem alten Mainboard. Dadurch konnte ich nicht nur den Banana Pi, sondern auch die inzwischen 5 Festplatten, die Fritzbox und einen zusätzlichen Switch an einem einzigen Netzteil betreiben, das noch reichlich Reserve für weitere Festplatten oder sonstige Erweiterungen bietet. Und es ist alles zusammen in einem einzigen Gehäuse untergebracht, nimmt nur wenig Platz weg und kommt mit einer einzigen Steckdose aus. Die Geschwindigkeit ist für mein 100MBit-Netzwerk bei weitem ausreichend, ich erreiche sowohl beim Lesen als auch beim Schreiben rund 11-12 MB/s, also das Maximum was das Netzwerk hergibt. Der Banana selbst hat einen Gigabit Port, so das hier auch noch deutlich mehr möglich wäre. Da ich aber keinen Gigabit Switch besitze, kann er bisher gar nicht seine volle Leistung entfalten.

So weit, so gut. Und weiter?

Ich werde auch in Zukunft die Speicherkapazität Stück für Stück ausbauen. Inzwischen sind es mehr als 5 Terabyte. Irgendwann werde ich auch den Switch durch ein Gigabit Modell ersetzen, und die Fritzbox ist auch schon ziemlich in die Jahre gekommen. Sie bietet leider nur ein 54MBit WLAN, was mir inzwischen doch zu langsam ist. Außerdem möchte ich gerne die Spannungen des Netzteils genau überwachen können, dafür werde ich einen PIC Mikrocontroller verwenden, der mit dem Banana verbunden wird. Eventuell kommt auch noch ein Display dazu, das dann drahtlos per XBee mit dem Server verbunden wird. Aber da bin ich mir noch nicht ganz sicher. Auch eine Überwachung der Lastströme auf den einzelnen Spannungen wäre denkbar, oder die temperaturabhängige Regelung der Lüfter. Die Abstellkammer in der mein Server steht ist direkt unter dem Dach, und im Sommer wird es da sehr heiß. Teile des Systems haben da schon mal 60 Grad erreicht, was für Festplatten schon ungesund ist.

Sobald ich den Server wieder umbaue, werde ich natürlich hier ausführlich berichten. Dann auch wieder mit Bildern und Details.