Posts by joshy

    Das ist doch gar kein C64C! C64C sind die flachen Gehäuse!

    Meins ist ein Brotkasten Gehäuse von Retro Fuzion (nagelneu) und das hat genug Schraubenlöcher mit eingepresster Mutter.

    Allerdings passen die Löcher nicht 100% übereinander, da muss man etwas bei tricksen. Auch musste man etwas vom Plastik beim Userport entfernen, da sonst die linke USB-Buchse nicht passte, ging aber einfach mit einem Cuttermesser.

    Ähnliche Frage wie Fepo - was für eine Blende ist für die rechte Seite am RF Brotkasten sinnvoll. Die original RF Blende funktioniert nicht, da man den Power-Schalter nicht nach unten drücken kann ;(


    Edit: ok Du warst schneller. Bei mir ist jetzt erst mal keine Blende dran.

    Ich behaupte ja nicht, dass es mit der API nicht geht. Es hängt davon ab, auf welcher Ebene man Zugriff bekommt. Wenn die API schon zu sehr abstrahiert, könnte es Probleme geben. Das muss gecheckt werden, das wollte ich sagen.

    Ich fürchte Du hast mit Deiner Befürchtung recht :(
    Ich habe mir mal die Funktion ibsad -- set secondary GPIB address angesehen weil die sich direkt auf die Sekundären Adressen bezieht.
    Die Funktion erlaubt tatsächlich nur die 7bit Sekundäradressen:

    pasted-from-clipboard.png


    Obwohl - da steht ja nur, dass der valid Range $60 bis $7E ist. Evtl. wird das aber nicht hart überprüft. Muss man halt ausprobieren. Mutmaßen hilft da nicht ;(

    D.h., für OPEN muss ein LISTEN gefolgt von einer speziellen Sekundäradresse (0xF0 + SA) gesendet werden, die IEEE488 gar nicht kennt.
    Für CLOSE entsprechend 0xE0 + SA.

    Ich behaupte ja nicht, dass es mit der API nicht geht. Es hängt davon ab, auf welcher Ebene man Zugriff bekommt. Wenn die API schon zu sehr abstrahiert, könnte es Probleme geben. Das muss gecheckt werden, das wollte ich sagen.

    Ja, den Punkt verstehe ich :) In der IEEE-488 Norm werden bei den Schnittstellennachrichten nur 7bit verwendet und Commodore benutzt noch das achte bit mit.
    pasted-from-clipboard.png


    pasted-from-clipboard.png

    Das kann u.U. Probleme bereiten, wenn eine Library Funktion die Nachrichten auf 7bit begrenzt oder nicht erlaubt, die secondary commands 'manuell' zu senden.

    So sehen die Schnittstellennachrichten in der Norm aus:
    pasted-from-clipboard.png


    Edit: die detaillierten Beispiele für die Verwendung des IEEE-488 Busses beim PET/CBM findet ihr im 'PET AND THE IEEE 488 BUS' ab Seite 68.

    Da ihr sowieso schon beim Thema seid: wird SQR von den alten CBM-Laufwerken und dem IEEE488-Bus tatsächlich verwendet, oder ist die Verbindung einfach nur da ?

    Der Service Request (SQR) ist ein wichtiger Bestandteil der IEEE-488 Funktion. Auf einer separaten Leitung der Schnittstelle können Geräte Handlungsbedarf an den Controller melden. Das ist wichtig, wenn Geräte unterschiedlicher Geschwindigkeit an einem Bus betrieben werden. Das langsamste Gerät bestimmt ja den Busverkehr. Die Geräte sowie der Controller müssen die Funktionalität natürlich auch softwareseitig unterstützen.


    Man kann z.B. einen Messvorgang auf einem Messgerät starten und das Gerät mit UNTALK/UNLISTEN vom aktiven Busverkehr trennen. Wenn das Gerät die Messung beendet hat, betätig es die SRQ Leitung. Der Controller stellt dann mittels Parallel- /Serial-Poll fest, welches Gerät sich gemeldet hat und holt dann gezielt die Daten ab.


    Auf dem CBM ist die SRQ Leitung an den CB1 Eingang der Bus-PIA angeschlossen. Im CBM Betriebssystem wird zur Verarbeitung des SRQ aber keine Funktion bereitgestellt. Den Teil kann man aber selber bereitstellen, wenn man SRQ verwenden möchte.

    Commodore hat ja einige proprietäre Erweiterungen - z.B. kennt IEEE488 gar kein OPEN und CLOSE

    Der IEEE-488 Bus hat mit den DOS Befehlen überhaupt nichts zu tun. Open und Close sind DOS Befehle und keine Erweiterungen der Bus-Befehle.

    Man muß bei Geräten mit einem IEEE-488 Bus sorgfältig zwischen Interface-Funktionen und Gerätefunktionen unterscheiden. Der Bus kennt weder die Funktionen eines Disk-Drives noch die Funktionen eines Multimeters. Das sind halt Gerätefunktionen die vom Bus zwischen den angeschlossenen Systemen transferiert werden.


    Insofern ist es egal, ob ein XUM1541 oder ein echtes IEEE-Interface zum Anschluß einer CBM Floppy an einen PC dient. Die Gerätefunktionen muss ein separates Programm auf dem PC abarbeiten.


    Bei der LINUX Integration werden die selben oder ähnliche Library Aufrufe wie bei der GPIB 488.2 Library unter Windows verwendet. Das ermöglicht natürlich eine einfache Portierung.
    Hier gibt's z.B. ein Tutorial zu einer Library unter Windows --> LINK

    Zum Vergleich Übersicht über die LINUX Library Funktionen --> LINK

    Der Linux Kernel bekommt bald nativen Support für den IEEE-488 Bus! Damit dürfte endlich der Weg frei sein für nativen Support von Commodore Floppylaufwerken! :-D

    Wie soll das funktionieren?
    Für ein IEEE-488 Interface ist ja erst einmal Hardware notwendig, die in keinem marktüblichen Computer standardmäßig verbaut ist. Entweder gibt es Interfacekarten von National Instruments, Meilhaus, Keithley,... oder USB nach IEEE-488 Schnittstellen, die aber alle auf unterschiedlicher Hardware basieren.
    Für diesen ganzen Kram werden individuelle Treiber benötigt.

    Sind also Treiber für die üblichsten Karten im Linux Kernal enthalten? Was wird sonst unterstützt, wenn von "nativen Support für den IEEE-488 Bus" geschrieben wird?
    Kennt jemand eine detallierte Stelle, wo man das nachlesen kann? Ich bin leider nicht so bewandert in der LINUX Dev. Doku.


    Auf alle Fälle ist der Weg noch lange nicht frei für nativen Support von Commodore Floppylaufwerken. Das Commodore DOS läuft halt nur über den IEEE-488 Bus, wird aber von einer Implementierung der Schnittstelle im Kernal nicht weiter unterstützt. Die Funktionen des Busses und des DOS werden leider immer wieder in einen Topf geworfen - und das ist sehr irreführend.

    Zum spielen mit einem Apple 1 habe ich mir die RC6502 Apple 1 Replica gebaut. Mit moderneren Bauteilen und der Video-/Tastaturteil wird über einen Ardurino Nano nachgebildet. Funktioniert aber mit dem originalen, unmodifizierten Woz-Mon. Zusätzlich ist das Integer-BASIC und ein Assembler im 8k EPROM.

    Im "12bits"-Modus sinkt die Abtastrate um die Hälfte. Im "14bit"-Modus sinkt sie nochmals deutlich.

    Ein echter 12bit- oder 14bit-Wandler würde aber natürlich immer mit seiner nativen Bitbreite arbeiten.

    -> ist offensichtlich kein echter 12bit oder gar 14bit-Wandler, sondern irgendeine Trickserei, um die Auflösung durch Mittelwertbildung o.ä. zu erhöhen.

    Beim Schritt auf "12bit" werden nach menschlichem Ermessen zwei Abtastungen gemittelt, wodurch die nutzbare Abtastrate halbiert wird.

    Was sie bei "14bit" genau treiben, weiß der Henker, aber daß die maximale Abtastrate um den Faktor 10 (!) kleiner wird, legt auch hier eine Mittelwertbildung mehrerer Abtastwerte nahe.

    Ja, die Überlegungen sind schon ok. Allerdings sind in den AE Modellen tatsächlich echte 14bit Wandler verbaut. Das Problem ist, dass die resultierenden Datenmengen bei 14bit im Digitalteil nicht mit voller Geschwindigkeit verarbeitet werden. Kann sein, dass die auch beim Speicher gespart haben.

    Wie Du schon geschrieben hast, ist das bei diesen preiswerten Geräten halt immer ein Kompromiss.

    Das sind halt so die Tricksereien, die ich persönlich für eher unprofessionell halte. Das ist nach menschlichem Ermessen ein 8bit-Scope mit 8bit-Wandlern, aber man kann halt zeitlich mitteln, was in etwa auf eine Erhöhung der Bits pro Sample rausläuft.

    Sorry, ich bin mit den Modellbezeichnungen durcheinandergeraten. Ich habe das XDS3104E und das hat natürlich auch offiziell einen 8bit Wandler. Es gibt das aber auch als

    XDS3104AE mit 14bit Wandlern.

    Ich habe seit einiger Zeit ein OWON XDS3104AE (4 Kanäle 100MHz 1GS/s 14Bit 40MS). Das Gerät ist gut - Bedienung und Funktionen bieten alles was man so braucht.

    Negativ zu bewerten sind allenfalls die Bedienköpfe, die keine Rastung haben und sich etwas wabbelig anfühlen.

    Was ist das für ein Gerät ? Plunscht oder bohrt die Maschine ?

    Obwohl bei 6m ist das auch mit einem Dreibein, 3 Kumpels und einer Kiste Bier in ein paar Stunden erledigt :hammer:

    Die 11m wurden gebohrt für ein DN125 Brunnenrohr. Das Loch hatte einen Durchmesser von ca. 20cm.

    Wenn es ab 6m Wasser gibt, musst Du trotzdem tiefer bohren, Du brauchst ja genügend Wasser im Rohr, wenn die Tauchpumpe arbeitet. Das Bohrteam hat für alle Arbeiten 2,5h gebraucht.

    Sorry - etwas offtopic

    Wieviel Raummeter haste da stehen? Mir scheint, als reicht das maximal ein Monat...

    Wenn das Regal voll ist sind gut 10 Raummeter. Wir heizen damit nur einen großen Kamin in einem großen zentralen Raum. Ca. 5 Raummeter reichen bei uns für eine Heizperiode.

    cool. da würde mich mal interessieren, was man für so einen Brunnen anlegen muß...

    Unser Brunnenbauer verlangt 80€ pro Meter bohren incl. Brunnenrohr. Allerdings sind 10m á 80€ pauschal - danach wird gebohrt, bis Wasser da ist. Bei uns gab's Grundwasser schon ab 6m - 11m benötigt man als Platz und Wasservorrat für die Tauchpumpe.
    Den Rest (Brunnengehäuse, Tauchpumpe, Druckschlauch, Druckschalter, Zapfstelle, etc.) kann man per Eigenleistung einbauen. Wir haben das ebenfalls bei unserem Brunnenbauer bestellt - zusätzlich zum Bohren für ca. 900€.

    Also ca. 1.800€ für die komplette Brunnenanlage.



    So soll das dann später auch bei uns aussehen :-)

    Ok - das hat nichts mit alten Computern zu tun, war aber wichtig.
    Gestern wurde mein Gartenbrunnen auf 11m Tiefe gebohrt. Ab 6m gabs Grundwasser und der Spiegel ist bei uns wegen des angrenzenden Sees recht konstant.


         


       


    Da wird noch eine Tauchpumpe mit Druckschalter installiert. Die Pumpe versorgt später die automatische Gartenbewässerung.